Index Scan vs Index Seek
寫這篇筆記是因為前陣子在實驗SQL查詢效能，發現自己對於「相似的SQL查詢有時使用Index Scan，有時又選擇Index Seek」的行為有些迷惑，決定花點時間重新認識這幾個基本資料庫概念。（對於SQL我只有玩票的水準，內容如有謬誤，敬請指正） 當我們對資料庫下達SELECT … WHERE …指令，資料庫引擎必須對指令進行分析，找出最有效率的方法儘快查到資料算出結果，而這個「找到資料算出結果的方法」就是所謂的執行計劃（Execution Plan）。要從資料表找到指定的資料，有很多做法，最笨的方法就是整個資料表每一筆都翻出來檢查（Scan），或者預先把常查的欄位拉出來排序做成索引（Index），找資料時先查索引，再透過索引指向資料所在位置。（就像查字典時由注音找到字，再翻到指定頁數） 以下是在資料表找資料的幾種做法： Table Scan 當資料表沒有任何Index，資料庫引擎唯一的選擇是讀取整個資料表逐筆比對。查詢過程耗費時間與結果筆數無關，因為整個資料表要掃一遍，這是最沒效率的做法。 Clustered Index Scan 當資料表有建立Clustered-Index，評估查詢條件無法藉由其他Index加速，資料庫引擎逐筆讀取整個Clustered Index進行比對，由於全部資料要掃一次，查詢耗費時間不受結果筆數影響。 由於Clustered Index順序與資料實際儲存順序一致，不需要額外尋找動作（例如：Key Lookup）就能讀到SELECT要求的欄位。 Index Scan 查詢條件包含Index的組成欄位，資料庫引擎逐筆讀取Index（由第一筆到最後一筆），從中找出符合者。若SELECT要求Index未包含的欄位，則還需透過Key Lookup找到資料列讀取資料。不管最後找到幾筆，都得讀完整個Index，尋找過程耗費時間與結果筆數無關（不考慮讀取資料時間）。 Index Seek 當查詢條件包含Index組成的第一個欄位（由此可知，建立多欄位Index時順序很重要），資料庫引擎可透過B Tree演算法較快找到第一筆相符資料，逐筆讀取直到資料不相符為止（如同Index Scan，必要時還需配合Key Lookup），Index Seek時間長短與結果筆數多寡成正比。 一般而言，Index See...