作者jengting (~~)
看板Database
標題Re: [SQL ] 非叢集索引掃描
時間Fri Sep 5 15:54:22 2014
※ 引述《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://webptt.com/m.aspx?n=bbs/Database/M.1409903664.A.DAC.html
1F：推 BigLoser: 先謝謝你，其實你說的我是知道的，只是對於index scan 09/05 18:39
2F：→ BigLoser: 這個東西不太了解，所以想問一下，PK -> table scan 09/05 18:40
3F：→ BigLoser: index -> index scan 那 index scan是會比table s 快 09/05 18:41
4F：→ BigLoser: 還是更慢(?)呢..我覺得奇怪的是在這邊 09/05 18:41
5F：推 sai25: 只要不是SEEK都不會快 討論TABLE SCAN或INDEX SCAN誰快 09/06 11:58
6F：→ sai25: 可能不太有意義 應該是都不快..重點是要SEEK 09/06 11:59
7F：推 sai25: 不過這兩個要比的話 應該是index比較快吧 09/06 14:21
8F：推 BigLoser: 謝謝，我知道的確是沒甚麼意義，只是對這個東西不太了解 09/06 14:58
9F：→ BigLoser: 那個資料庫和程式端都不是我在管的=_= 09/06 14:59
10F：→ BigLoser: 只是無聊進去看一下發現的..已告知負責的人修改 09/06 14:59
11F：推 rockchangnew: Index scan會比較快，因為資料量的關係 09/07 17:15
12F：推 rockchangnew: 但如果index無法滿足查詢，需在scan過程回table取 09/07 17:17
13F：→ rockchangnew: 資料則index scan會比較慢 09/07 17:18
14F：→ jengting: SQL Server 是 Costly-base 而不是 Rule-base， 09/09 08:39
15F：→ jengting: 針對某一個點討論效能其實沒有意義 09/09 08:39
16F：推 BigLoser: 也是，學習了! 謝謝 09/09 09:35