在資料庫操作中，一個全表掃描(full table scan)可能是整個應用的瓶頸，因此，我們盡量
要避免不必要的全表掃描。而如果你發現一條sql是全表掃描，一般的解決步驟是：
1、運行執行計劃獲得具體的sql語句查詢分析：
方法：explain sql;
分析：至少能或得這些信息，1、表的join順序(按計劃的上到下join)， 2、是否
使用索引，3、可能會使用的索引
2、添加對應的索引，或是重寫查詢sql，或更換join順序等
3、如果查詢對當前的結構不滿意，可以考慮重建表
下面分別說一下全表掃描可能發生的情形：
1、在on或者where字句中,使用的列沒有索引，可以考慮加一個索引
2、表很小，大約少於10行，這個沒有什麼危害，因為即使你有索引，優化器也會判斷
在邊讀索引邊取數據時，直接全表掃描快些
3、你在一個where字句中使用含有索引的列，但這個列的值很集中化，比如欄位 gender,
這個的值就兩個值male 和 female，如果使用索引反而會慢些，不使用索引會更快，這
種情況不用擔心
4、這個跟第三條類似，就是當你的一個索引，他的每個鍵對應多個值，即基數很低
(low cardinality)，因此可能會選擇全表掃描
下面說一下對與避免發生全部掃描的時間:
1、對於使用or查詢的語句，這種查詢可能會產生全表掃描，他的策略是以一個一個比較
如果符合要求，則選出來，但這樣的操作會很慢，我們可以用union來做這樣的查詢，
當然union要快的前提是，你對兩個條件都有索引，如：
select * from table1 where key1 < 10 or key2 > 60
可以更改為：
select * from table1 where key1 < 10 union select * from table1 where key2 >60
2、對於使用memory引擎的，建立索引時，默認是hash索引，這個的支出的訪問單行數據很快，
但如果你有類似的范圍操作如>= , <= , between 時，可以考慮建立索引用btree類型的，方法為:
create index index_name on table(col_name) using btree;
3、當你分析確定必須使用某個索引，但執行計劃卻不使用該索引，可以使用force index,方法為:
select * from table_name force index index_name where clause
4、使用analyze table table_name來更新索引的鍵的分布，這個會影響jion表的順序
用索引和用不到索引的區別：
㈡ SQL語句在什麼情況下使用全表掃描
下面簡單介紹SQL中哪些情況會引起全表掃描。
1、模糊查詢效率很低：
原因：like本身效率就比較低，應該盡量避免查詢條件使用like；對於like
『%...%』（全模糊）這樣的條件，是無法使用索引的，全表掃描自然效率很低；另外，由於匹配演算法的關系，模糊查詢的欄位長度越大，模糊查詢效率越低。
2、查詢條件中含有is
null的select語句執行慢
3
、查詢條件中使用了不等於操作符（<>、!=）的select語句執行慢
原因：SQL中，不等於操作符會限制索引，引起全表掃描，即使比較的欄位上有索引
4、or語句使用不當會引起全表掃描
原因：where子句中比較的兩個條件，一個有索引，一個沒索引，使用or則會引起全表掃描。例如：where
A==1
or
B==2，A上有索引，B上沒索引，則比較B==2時會重新開始全表掃描。
5、組合索引
，排序時應按照組合索引中各列的順序進行排序，即使索引中只有一個列是要排序的，否則排序性能會比較差。
6、Update
語句
，如果只更改1、2個欄位，不要Update全部欄位，否則頻繁調用會引起明顯的性能消耗，同時帶來大量日誌。
7
、對於多張大數據量（
這里幾百條就算大了）的表JOIN，要先分頁再JOIN，否則邏輯讀會很高，性能很差。
參考資料：
http://www.studyofnet.com/news/131.html
希望以上的回答能夠幫助你！
㈢ SQL中哪些情況會引起全表掃描
解決辦法：首先盡量避免模糊查詢，如果因為業務需要一定要使用模糊查詢，則至少保證不要使用全模糊查詢，對於右模糊查詢，即like
『…%』，是會使用索引的；左模糊like
『%...』無法直接使用索引，但可以利用reverse
+
function
index
的形式，變化成
like
『…%』；全模糊是無法優化的，一定要的話考慮用搜索引擎。出於降低資料庫伺服器的負載考慮，盡可能地減少資料庫模糊查詢。
2、查詢條件中含有is
null的select語句執行慢
原因：oracle
9i中，查詢欄位is
null時單索引失效，引起全表掃描。
解決方法：sql語法中使用null會有很多麻煩，最好索引列都是not
null的；對於is
null，可以建立組合索引，nvl(欄位,0),對表和索引analyse後，is
null查詢時可以重新啟用索引查找,但是效率還不是值得肯定；is
not
null
時永遠不會使用索引。一般數據量大的表不要用is
null查詢。
3、查詢條件中使用了不等於操作符（、!=）的select語句執行慢
原因：sql中，不等於操作符會限制索引，引起全表掃描，即使比較的欄位上有索引
解決方法：通過把不等於操作符改成or，可以使用索引，避免全表掃描
㈣ SQL注入漏洞掃描工具有哪些
WebCruiser Web Vulnerability Scanner是一個功能不凡的Web應用漏洞掃描器，能夠對整個網站進行漏洞掃描，並能夠對發現的漏洞（SQL注入，跨站腳本）進行驗證；它也可以單獨進行漏洞驗證。
網站爬蟲（目錄及文件）；
漏洞掃描（SQL注入，跨站腳本）；
漏洞驗證（SQL注入，跨站腳本）；
SQL Server明文/欄位回顯/盲注；
MySQL欄位回顯/盲注；
Oracle欄位回顯/盲注；
DB2欄位回顯/盲注；
Access欄位回顯/盲注；
管理入口查找；
GET/Post/Cookie 注入；
搜索型注入延時；
自動從自帶瀏覽器獲取Cookie進行認證；
自動判斷資料庫類型；
自動獲取關鍵詞；
多線程；
高級：代理、敏感詞替換/過濾；
報告；WebCruiser Web Vulnerability Scanner是一個功能不凡的Web應用漏洞掃描器，能夠對整個網站進行漏洞掃描，並能夠對發現的漏洞（SQL注入，跨站腳本）進行驗證；它也可以單獨進行漏洞驗證。
網站爬蟲（目錄及文件）；
漏洞掃描（SQL注入，跨站腳本）；
漏洞驗證（SQL注入，跨站腳本）；
SQL Server明文/欄位回顯/盲注；
MySQL欄位回顯/盲注；
Oracle欄位回顯/盲注；
DB2欄位回顯/盲注；
Access欄位回顯/盲注；
管理入口查找；
GET/Post/Cookie 注入；
搜索型注入延時；
自動從自帶瀏覽器獲取Cookie進行認證；
自動判斷資料庫類型；
自動獲取關鍵詞；
多線程；
高級：代理、敏感詞替換/過濾；
報告；
㈤ 跪求區域網SQL Server伺服器掃描查詢工具 V1.0 綠色版軟體百度雲資源
鏈接:
提取碼:5vkf
軟體名稱:區域網SQLServer伺服器掃描查詢工具V1.0綠色版
語言:簡體中文
大小:1.4MB
類別:系統工具
介紹:區域網SQLServer伺服器掃描查詢工具是一款相當出色的區域網內資料庫掃描工具，此款軟體功能強悍，能夠幫助用戶輕松地掃描查看區域網中的所有SQLServer資料庫，區域網SQLServer伺服器掃描查詢工具便捷好用，還可以查看資料庫結構，進行簡單增刪查改等操作。
㈥ 如何防範SQL注入漏洞及檢測
以下是OMG我為大家收集整理的文章，希望對大家有所幫助。
SQL注入(SQLInjection)漏洞攻擊是目前網上最流行最熱門的黑客腳本攻擊方法之一，那什麼是SQL注入漏洞攻擊呢?它是指黑客利用一些Web應用程序(如：網站、論壇、留言本、文章發布系統等)中某些存在不安全代碼或SQL語句不縝密的頁面，精心構造SQL語句，把非法的SQL語句指令轉譯到系統實際SQL語句中並執行它，以獲取用戶名、口令等敏感信息，從而達到控制主機伺服器的攻擊方法。
1. SQL注入漏洞攻擊原理
1. 1 SQL注入漏洞攻擊實現原理
SQL(Structured Query Language)是一種用來和資料庫交互的語言文本。SQL注入的攻擊原理就是攻擊者通過Web應用程序利用SQL語句或字元串將非法的數據插入到伺服器端資料庫中，獲取資料庫的管理用戶許可權，然後將資料庫管理用戶許可權提升至操作系統管理用戶許可權，控制伺服器操作系統，獲取重要信息及機密文件。
SQL注入漏洞攻擊主要是通過藉助於HDSI、NBSI和Domain等SQL注入漏洞掃描工具掃描出Web頁面中存在的SQL注入漏洞，從而定位SQL注入點，通過執行非法的SQL語句或字元串達到入侵者想要的操作。下面以一段身份驗證的.NET代碼為例，說明一下SQL 注入攻擊的實現方法。
SqlConnectionnwConn = new SqlConnection((string)ConfigurationSettings.AppSettings["DBconnStrings"]); string queryStr = "SELECT userid,userpwd, username,type FROM users where userid='" + Txtusername.Text +"'";
DataSet userSet = new DataSet();
SqlDataAdapter userAdapter = newSqlDataAdapter(queryStr, nwConn);
userAdapter.Fill(userSet, "Users");
Session["UserID"] =Txtusername.Text.ToString();
Session["type"] =type.Text.ToString();
Response.Redirect("/Myweb/admin/login.aspx");
從上面的代碼中可以看出,程序在與資料庫建立連接得到用戶數據之後,直接將username的值通過session傳給login.aspx，沒有進行任何的過濾和處理措施, 直接用來構造SQL 語句, 其危險系數是非常高的, 攻擊者只要根據SQL 語句的編寫規則就可以繞過身份驗證，從而達到入侵的目的。
1. 2 SQL注入漏洞攻擊分析
SQL注入可以說是一種漏洞，也可以說是一種攻擊。當程序中的變數處理不當，沒有對用戶提交的數據類型進行校驗，編寫不安全的代碼，構造非法的SQL語句或字元串，都可能產生這個漏洞。
例如Web系統有一個login頁面，這個login頁面控制著用戶是否有權訪問，要求用戶輸入一個用戶名和口令，連接資料庫的語句為：
“select * from users where username = 'username' andpassword = 'password'”
攻擊者輸入用戶名為aa or 1=1口令為1234 or 1=1之類的內容。我們可以看出實際上攻擊者並不知道真正的用戶名、口令，該內容提交給伺服器之後，伺服器執行攻擊者構造出的SQL命令，但由於攻擊者輸入的內容非常特殊，所以最後得到的SQL命令變成：
“select * from users where username = 'aa' or 1=1 andpassword = '1234' or 1=1”
伺服器執行查詢或存儲過程，將用戶輸入的身份信息和資料庫users表中真實的身份信息進行核對，由於SQL命令實際上已被修改，存在永遠成立的1=1條件，因此已經不能真正驗證用戶身份，所以系統會錯誤地授權攻擊者訪問。
SQL 注入是通過目標伺服器的80埠進行的，是正常的Web訪問，防火牆不會對這種攻擊發出警告或攔截。當Web伺服器以普通用戶的身份訪問資料庫時，利用SQL注入漏洞就可能進行創建、刪除、修改資料庫中所有數據的非法操作。而當資料庫以管理用戶許可權的身份進行登錄時，就可能控制整個資料庫伺服器。
SQL注入的方法很多，在以手動方式進行攻擊時需要構造各種各樣的SQL語句，所以一般攻擊者需要豐富的經驗和耐心，才能繞過檢測和處理，提交語句，從而獲得想要的有用信息。這個過程需要花費很多的時間，如果以這種手動方式進行SQL注入漏洞攻擊，許多存在SQL注入漏洞的ASP、JSP、PHP、JAVA等網站就會安全很多了，不是漏洞不存在了，而是手動入侵者需要編程基礎，但現在攻擊者可以利用一些現成的黑客工具來輔助SQL注入漏洞攻擊，加快入侵的速度，使SQL注入變得輕而易舉。
由於SQL注入漏洞攻擊利用的是通用的SQL語法，使得這種攻擊具有廣泛性。理論上說，對於所有基於SQL語言的資料庫管理系統都是有效的，包括MSSQLServer、Oracle、DB2、Sybase和MySQL等。當然，各種系統自身的SQL擴展功能會有所不同，因此最終的攻擊代碼可能不盡相同。
1. 3 SQL注入漏洞攻擊過程
(1)繞過身份驗證
如一個login界面，需要輸入用戶名和口令，然後Post到另一個頁面，進行身份驗證,因此攻擊者只需在用戶名和口令的輸入框中都輸入aa or’1’=’1’的內容，那麼攻擊者就可以通過欺騙的驗證方式而直接進入下一個頁面，並擁有和正常登錄用戶一樣的全部特權。原因是什麼呢? 我們比較一下正常用戶登錄和攻擊者登錄時的兩種SQL語句：
1)正常用戶(如用戶名為admin，口令為1234567) ：
SQL= " selectfrom users where username = ’admin’and password= ’1234567’ ";
2)攻擊者(用戶名和口令都為aa or’1’=’1’) ：
SQL= " select * from users where username='aa or’1’=’1’'and password = ' aa or’1’=’1’'";
可以看到由and連接的兩個條件都被一個永遠成立的1=1所代替，執行的結果為true，資料庫會認為條件恆成立，會返回一個true，讓攻擊者以合法身份登錄進入下一個頁面。
(2)執行非法操作
如一個查詢頁面select1.asp? id=1，編程人員原本設計意圖是顯示id為1的查詢信息，而攻擊者利用程序中沒有對id內容進行檢查的機制，插入自己的代碼。
從select1.asp中摘錄一段關鍵代碼：
SQL= " select *from photo where photoid= 'id'";
可以看到，id沒有進行任何的處理，直接構成SQL語句並執行，而攻擊者在知道該系統資料庫中表名及欄位名的情況下，利用SQL語句特性(分號是將兩句SQL 語句分開的符號)，直接向資料庫Tuser表中添加記錄：
select1.asp? id= 1;Insertinto Tuser (username,password,type) values ('hack','1234567','管理員')，然後攻擊者就可以直接用hack進行登錄了。通過這樣的方法，攻擊者還可以對系統做任何的事情，包括添加、刪除、修改系統資源的操作。
(3)執行系統命令
如果Web主機使用MSSQL資料庫管理系統，那麼攻擊者就可以用到xp_cmdshell這個擴展存儲過程，xp_cmdshell是一個非常有用的擴展存儲過程，用於執行系統命令，比如dir、net等，攻擊者可以根據程序的不同，提交不同的語句：
execmaster.dbo.xp_cmdshell " dir "; exec master.dbo.xp_cmdshell" net user hack 1234567 /add ";
execmaster.dbo.xp_cmdshell " net localgroup administrators hack /add ";
這樣就可以向Web主機系統中成功添加了一個管理員帳戶。
2. SQL注入漏洞攻擊的檢測方式及方法
2. 1檢測方式
SQL注入漏洞攻擊檢測分為入侵前的檢測和入侵後的檢測。入侵前的檢測，可以通過手工方式，也可以使用SQL注入漏洞掃描工具軟體。檢測的目的是為預防SQL注入漏洞攻擊，而對於SQL注入漏洞攻擊後的檢測，主要是針對審計日誌的查看，SQL注入漏洞攻擊成功後，會在Web Service和資料庫的審計日誌中留下“痕跡”。
2. 2檢測方法
(1)動態SQL檢查
動態的SQL語句是一個進行資料庫查詢的強大的工具，但把它和用戶輸入混合在一起就使SQL注入成為了可能。將動態的SQL語句替換成預編譯的SQL或者存儲過程對大多數應用程序是可行的。預編譯的SQL或者存儲過程可以將用戶的輸入作為參數而不是命令來執行，這樣就限制了入侵者的行動。當然，它不適用於存儲過程中利用用戶輸入來生成SQL命令的情況。在這種情況下，用戶輸入的SQL命令仍可能得到執行，資料庫仍然存在SQL注入漏洞攻擊的危險。
(2)有效性校驗
如果一個輸入框只可能包括數字，那麼要通過驗證確保用戶輸入的都是數字。如果可以接受字母，檢查是不是存在不可接受的字元，那就需要設置字元串檢查功能。確保應用程序要檢查以下字元：分號、等號、破折號、括弧以及SQL關鍵字。
(3)數據表檢查
使用SQL注入漏洞攻擊工具軟體進行SQL注入漏洞攻擊後，都會在資料庫中生成一些臨時表。通過查看資料庫中最近新建的表的結構和內容，可以判斷是否曾經發生過SQL注入漏洞攻擊。
(4)審計日誌檢查
在Web伺服器中如果啟用了審計日誌功能，則Web Service審計日誌會記錄訪問者的IP地址、訪問時間、訪問文件等信息，SQL注入漏洞攻擊往往會大量訪問某一個頁面文件(存在SQL注入點的動態網頁)，審計日誌文件會急劇增加，通過查看審計日誌文件的大小以及審計日誌文件中的內容，可以判斷是否發生過SQL注入漏洞攻擊事件;另外還可以通過查看資料庫審計日誌，查詢某個時間段是否有非法的插入、修改、刪除操作。
(5)其他
SQL注入漏洞攻擊成功後，入侵者往往會添加特權用戶(如：administrator、root、sa等)、開放非法的遠程服務以及安裝木馬後門程序等，可以通過查看用戶帳戶列表、遠程服務開啟情況、系統最近日期產生的一些文件等信息來判斷是否發生過入侵。
3. SQL注入漏洞防範措施
SQL注入漏洞攻擊的防範方法有很多種，現階段總結起來有以下方法：
(1)數據有效性校驗。如果一個輸入框只可能包括數字，那麼要通過校驗確保用戶輸入的都是數字。如果可以接受字母，那就要檢查是不是存在不可接受的字元，最好的方法是增加字元復雜度自動驗證功能。確保應用程序要檢查以下字元：分號、等號、破折號、括弧以及SQL關鍵字。另外限製表單數據輸入和查詢字元串輸入的長度也是一個好方法。如果用戶的登錄名最多隻有10個字元，那麼不要認可表單中輸入10個以上的字元，這將大大增加攻擊者在SQL命令中插入有害代碼的難度。
(2)封裝數據信息。對客戶端提交的數據進行封裝，不要將數據直接存入cookie中，方法就是在編程的代碼中，插入session、if、try、else，這樣可以有效地防止攻擊者獲取cookie中的重要信息。
(3)去除代碼中的敏感信息。將在代碼中存在的用戶名、口令信息等敏感欄位刪除，替換成輸入框。
SQL=" select from users where username = ’admin’and password= ’1234567’ "
如：這樣顯然會暴露管理員的用戶名、口令信息。可以將其修改成：
SQL= " select * from users where username='" +Txtuser.Text + "' and userpwd='" + Textpwd.Text + "'"
這樣就安全了很多，入侵者也是不會輕易的就獲取到用戶名、口令信息。
(4)替換或刪除單引號。使用雙引號替換掉所有用戶輸入的單引號，這個簡單的預防措施將在很大程度上預防SQL注入漏洞攻擊，單引號時常會無法約束插入數據的Value，可能給予輸入者不必要的許可權。用雙引號替換掉單引號可以使大部分SQL注入漏洞攻擊失敗。 如：
“select* from users where username='" + admin + "' and userpwd='" + 1234567+ "'”
顯然會得到與
“select * from users where username='admin' and password= '1234567'”
相同的結果。
(5)指定錯誤返回頁面。攻擊者有時從客戶端嘗試提交有害代碼和攻擊字元串，根據Web Service給出的錯誤提示信息來收集程序及伺服器的信息，從而獲取想得到的資料。應在Web Service中指定一個不包含任何信息的錯誤提示頁面。
(6)限制SQL字元串連接的配置文件。使用SQL變數，因為變數不是可以執行的腳本，即在Web頁面中將連接資料庫的SQL字元串替換成指定的Value，然後將Web.config文件進行加密，拒絕訪問。
(7)設置Web目錄的訪問許可權。將虛擬站點的文件目錄禁止遊客用戶(如：Guest用戶等)訪問，將User用戶許可權修改成只讀許可權，切勿將管理許可權的用戶添加到訪問列表。
(8)最小服務原則。Web伺服器應以最小許可權進行配置，只提供Web服務，這樣可以有效地阻止系統的危險命令，如ftp、cmd、vbscript等。
(9)鑒別信息加密存儲。將保存在資料庫users表中的用戶名、口令信息以密文形式保存，也可以對users表進行加密處理，這樣可以大大增加對鑒別信息訪問的安全級別。
(10)用戶許可權分離。應盡可能的禁止或刪除資料庫中sa許可權用戶的訪問，對不同的資料庫劃分不同的用戶許可權，這樣不同的用戶只能對授權給自己的資料庫執行查詢、插入、更新、刪除操作，就可以防止不同用戶對非授權的資料庫進行訪問。
4. 結束語
SQL注入漏洞攻擊在網上非常普遍，許多ASP、PHP論壇和文章管理系統、下載系統以及新聞系統都存在這個漏洞。造成SQL注入漏洞攻擊的主要原因是開發人員在系統開發的過程中編程不規范，沒有形成良好的編程習慣，問題的解決只有依賴於規范編程。此外，也可以使用現有的SQL注入漏洞掃描器對整個網站中的關鍵代碼進行掃描，查找網站頁面中存在的SQL注入點。對於有問題的頁面，可以及時刪除或更新。本文通過對SQL注入漏洞攻擊的方法、原理以及攻擊實施過程進行了闡述和總結，並給出了一些常見的SQL注入漏洞攻擊防範的方法。
㈦ 在SQL中當全表掃描時會發生什麼情況
全表掃描是指整個表的數據檢索一次
比如：
name age
張三 90
李四 80
王五 100
這時你查 age小於80時就是一行一行記錄的掃描下去，直至到最後一行；因為數據表不知道哪一行的age小於80。
防止掃描整張表的方法有很多，但不一定都能防止得了或者值得去實現。
主要有採用索引的方式，欄位被定義為主鍵或unique會自動添加索引。
以上表為例，可以添加age為索引；這樣資料庫就會開辟另一個空間對這個列進行排序。
類似這樣：
name age
李四 80
張三 90
王五 100
這樣的話，當掃描到李四這條記錄的時候，資料庫就知道了下面的記錄age是大於80的，就只會掃描一次。所以大大提高了效率。至於這方面的資料有很多，樓主可以去網路一下。
㈧ SQL Server中SCAN 和SEEK的區別
SQL SERVER
使用掃描（scan）和查找（seek）這兩種演算法從數據表和索引中讀取數據。這兩種演算法構成了查詢的基礎，幾乎無處不在。Scan
會掃描並且返回整個表或整個索引。 而 seek
則更有效率，根據謂詞（predicate），只返索引內的一個或多個范圍內的數據。下面將以如下的查詢語句作為例子來分析 scan 和 seek：
select OrderDate from Orders where OrderKey = 2
Scan
使用 Scan 的方式，SQL Server 會去讀取 Orders 表中的每一行數據，讀取的時候評估是否滿足謂詞 「where
order＝2」。如果滿足（數據行符合條件），則返回該行。這個例子里，我們將這個謂詞稱作「resial
predicate」。為了得到最優的性能，SQL 會盡可能地在掃描中使用「resial predicate」。但如果 resial
predicate 的開銷過於昂貴，SQL Server 可能會使用單獨的「filter iterator」. 「resial
predicate」以 where 關鍵字的形式出現在文本格式的 plan 中。對 XML 格式的
plan，則是<predicate>標記的形式。
下面這個掃描的文本格式的 plan 的結果：
–Table Scan (OBJECT:([ORDERS])， WHERE:([ORDERKEY]=(2)))
下圖說明了掃描的方式：
無論數據行是否滿足條件，掃描的讀取方式都會訪問表中的每一個數據，所以 scan 的成本和表的數據總量是成比例的。
因此，如果表很小或者表內的大多數數據多滿足謂詞，scan 是一種有效率的讀取方式。然而如果表很大或者絕大多數的數據並不滿足謂詞，
那麼這種方式會讓我們訪問到太多不需要的數據頁面，並執行更多的額外的 IO 操作。
Seek
繼續以上面的查詢為例子，如果在 orderkey 列上有一個索引，那麼 seek 可能會是一個好的選擇。使用 seek
的訪問方式，SQL Server 會使用索引直接導向到滿足謂詞條件的數據行。 這個例子里，我們將這個謂詞稱為「seek predicate」。
大多數情況下，SQL Server 不必將「seek predicate」重新評估為「resial predicate」。
索引會保證「seek」只返回符合條件的數據行。「seek predicate」以 seek 關鍵字的形式出現在文本格式的 plan 中。 對於
xml 格式的 plan,則以<seekpredicates>標記出現。
下面是使用 seek 的文本格式的 plan 的結果：
–Index Seek (OBJECT:([ORDERS].[OKEY_IDX])， SEEK:([ORDERKEY]=(2)) ORDERED FORWARD)
使用 seek 時，SQL Server
只會直接訪問到滿足條件的數據行和數據頁，因此它的成本只跟滿足條件的數據行的及其相應的數據頁面數量成比例， 和基表的數據量完全沒有關系。因此，如果
對於一個選擇性很高（通過這個謂詞，可以篩選掉表中的大部分數據）的謂詞條件，seek 是非常高效的。
下面的表格列出了 seek 和 scan 這兩種查找方式和堆表，聚簇索引和非聚簇索引的各種組合：
Scan
Seek
Heap
Table Scan
Clustered Index
Clustered Index Scan
Clustered Index Seek
Non-Clustered Index
Index Scan
Index Seek