※ 引述《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 並沒有充分發揮索引

先謝謝你，其實你說的我是知道的，只是對於index scan這個東西不太了解，所以想問一下，PK -> table scanindex -> index scan 那 index scan是會比table s 快還是更慢(?)呢..我覺得奇怪的是在這邊

只要不是SEEK都不會快 討論TABLE SCAN或INDEX SCAN誰快可能不太有意義 應該是都不快..重點是要SEEK不過這兩個要比的話 應該是index比較快吧

謝謝，我知道的確是沒甚麼意義，只是對這個東西不太了解那個資料庫和程式端都不是我在管的=_=只是無聊進去看一下發現的..已告知負責的人修改

Index scan會比較快，因為資料量的關係但如果index無法滿足查詢，需在scan過程回table取資料則index scan會比較慢

SQL Server 是 Costly-base 而不是 Rule-base，針對某一個點討論效能其實沒有意義

也是，學習了! 謝謝