Re: [SQL ] 非叢集索引掃描

看板Database作者 (~~)時間9年前 (2014/09/05 15:54), 編輯推噓7(7推 0噓 9→)
留言16則, 4人參與, 最新討論串2/2 (看更多)
※ 引述《BigLoser (大魯蛇)》之銘言： : 最近看了一個mssql 2012的資料庫， : 索引的報表裡面有一個index，被index scan的機率還不低， : 而且這個table沒有做PK，不過這個index有設唯一， : 網路上看到說，如果你的PK被index scan那狀況就是table scan， : 那我現在這個狀況也是table scan嗎? : 需要改善查詢語法嗎? : 謝謝喔 透過 SSMS 內建立 Primary Key 預設就是 Clustered Index， 根據有沒有 Clustered Index 可以把 Table 分為兩種架構， 1. 沒有 Clustered Index 的架構 - Heap，會是 Table Scan 2. 有 Clustered Index 的架構 - B-Tree，會是 Index Scan 建立一個 Table，透過執行計畫就可以觀察到有沒有 Clustered Index 的 Scan 模式 通常會建議要建立 Clustered Index，假如沒有明確的 Primary Key 欄位， 可以建立一個 identity 或 Sequence 欄位來當 Primary Key 這一點可以 Google "sql heap vs clustered index" 可以找到參考資料 個人意見：Index Scan 或 Table Scan 應該不是重點， 重點是 Scan 代表 T-SQL 並沒有充分發揮索引 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.158.7 ※ 文章網址: http://www.ptt.cc/bbs/Database/M.1409903664.A.DAC.html
推
09/05 18:39, , 1F
先謝謝你，其實你說的我是知道的，只是對於index scan
09/05 18:39, 1F
→
09/05 18:40, , 2F
這個東西不太了解，所以想問一下，PK -> table scan
09/05 18:40, 2F
→
09/05 18:41, , 3F
index -> index scan 那 index scan是會比table s 快
09/05 18:41, 3F
→
09/05 18:41, , 4F
還是更慢(?)呢..我覺得奇怪的是在這邊
09/05 18:41, 4F
推
09/06 11:58, , 5F
只要不是SEEK都不會快 討論TABLE SCAN或INDEX SCAN誰快
09/06 11:58, 5F
→
09/06 11:59, , 6F
可能不太有意義 應該是都不快..重點是要SEEK
09/06 11:59, 6F
推
09/06 14:21, , 7F
不過這兩個要比的話 應該是index比較快吧
09/06 14:21, 7F
推
09/06 14:58, , 8F
謝謝，我知道的確是沒甚麼意義，只是對這個東西不太了解
09/06 14:58, 8F
→
09/06 14:59, , 9F
那個資料庫和程式端都不是我在管的=_=
09/06 14:59, 9F
→
09/06 14:59, , 10F
只是無聊進去看一下發現的..已告知負責的人修改
09/06 14:59, 10F
推
09/07 17:15, , 11F
Index scan會比較快，因為資料量的關係
09/07 17:15, 11F
推
09/07 17:17, , 12F
但如果index無法滿足查詢，需在scan過程回table取
09/07 17:17, 12F
→
09/07 17:18, , 13F
資料則index scan會比較慢
09/07 17:18, 13F
→
09/09 08:39, , 14F
SQL Server 是 Costly-base 而不是 Rule-base，
09/09 08:39, 14F
→
09/09 08:39, , 15F
針對某一個點討論效能其實沒有意義
09/09 08:39, 15F
推
09/09 09:35, , 16F
也是，學習了! 謝謝
09/09 09:35, 16F
‣ 更多 jengting 的文章
文章代碼(AID): #1K2Mmmsi (Database)
‣ 更多 jengting 的文章
文章代碼(AID): #1K2Mmmsi (Database)