SQL索引在數據庫優化中占有一個非常大的比例，?一個好的索引的設計，可以讓你的效率提高幾十甚至幾百倍，在這里將帶你一步步揭開他的神秘面紗。

1、什么是索引？

SQL索引有兩種，聚集索引和非聚集索引，索引主要目的是提高了SQL?Server系統的性能，加快數據的查詢速度與減少系統的響應時間?

下面舉兩個簡單的例子：

圖書館的例子：一個圖書館那么多書，怎么管理呢？建立一個字母開頭的目錄，例如：a開頭的書，在第一排，b開頭的在第二排，這樣在找什么書就好說了，這個就是一個聚集索引，可是很多人借書找某某作者的，不知道書名怎么辦？圖書管理員在寫一個目錄，某某作者的書分別在第幾排，第幾排，這就是一個非聚集索引

字典的例子：字典前面的目錄，可以按照拼音和部首去查詢，我們想查詢一個字，只需要根據拼音或者部首去查詢，就可以快速的定位到這個漢字了，這個就是索引的好處，拼音查詢法就是聚集索引，部首查詢就是一個非聚集索引.

??? 看了上面的例子，下面的一句話大家就很容易理解了：聚集索引存儲記錄是物理上連續存在，而非聚集索引是邏輯上的連續，物理存儲并不連續。就像字段，聚集索引是連續的，a后面肯定是b，非聚集索引就不連續了，就像圖書館的某個作者的書，有可能在第1個貨架上和第10個貨架上。還有一個小知識點就是：聚集索引一個表只能有一個，而非聚集索引一個表可以存在多個。

2、索引的存儲機制

首先，無索引的表，查詢時，是按照順序存續的方法掃描每個記錄來查找符合條件的記錄，這樣效率十分低下,舉個例子，如果我們將字典的漢字隨即打亂，沒有前面的按照拼音或者部首查詢，那么我們想找一個字，按照順序的方式去一頁頁的找，這樣效率有多底，大家可以想象。

???????聚集索引和非聚集索引的根本區別是表記錄的排列順序和與索引的排列順序是否一致，其實理解起來非常簡單，還是舉字典的例子：如果按照拼音查詢，那么都是從a-z的，是具有連續性的，a后面就是b，b后面就是c，?聚集索引就是這樣的，他是和表的物理排列順序是一樣的，例如有id為聚集索引，那么1后面肯定是2,2后面肯定是3，所以說這樣的搜索順序的就是聚集索引。非聚集索引就和按照部首查詢是一樣是，可能按照偏房查詢的時候，根據偏旁‘弓’字旁，索引出兩個漢字，張和弘，但是這兩個其實一個在100頁，一個在1000頁，（這里只是舉個例子），他們的索引順序和數據庫表的排列順序是不一樣的，這個樣的就是非聚集索引。

??????原理明白了，那他們是怎么存儲的呢？在這里簡單的說一下，聚集索引就是在數據庫被開辟一個物理空間存放他的排列的值，例如1-100，所以當插入數據時，他會重新排列整個整個物理空間，而非聚集索引其實可以看作是一個含有聚集索引的表，他只僅包含原表中非聚集索引的列和指向實際物理表的指針。他只記錄一個指針，其實就有點和堆棧差不多的感覺了

3、什么情況下設置索引

動作描述	使用聚集索引?	?使用非聚集索引
?外鍵列	?應	?應
?主鍵列	?應	?應
?列經常被分組排序(order?by)	?應	?應
?返回某范圍內的數據	?應	?不應
?小數目的不同值	?應	?不應
?大數目的不同值	?不應	?應
?頻繁更新的列	不應?	?應
?頻繁修改索引列	?不應	?應
?一個或極少不同值	?不應	?不應

建立索引的原則：

1)?定義主鍵的數據列一定要建立索引。

2)?定義有外鍵的數據列一定要建立索引。

3)?對于經常查詢的數據列最好建立索引。

4)?對于需要在指定范圍內的快速或頻繁查詢的數據列;

5)?經常用在WHERE子句中的數據列。

6)?經常出現在關鍵字order?by、group?by、distinct后面的字段，建立索引。如果建立的是復合索引，索引的字段順序要和這些關鍵字后面的字段順序一致，否則索引不會被使用。

7)?對于那些查詢中很少涉及的列，重復值比較多的列不要建立索引。

8)?對于定義為text、image和bit的數據類型的列不要建立索引。

9)?對于經常存取的列避免建立索引?

9)?限制表上的索引數目。對一個存在大量更新操作的表，所建索引的數目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響數據的更新操作。

10)?對復合索引，按照字段在查詢條件中出現的頻度建立索引。在復合索引中，記錄首先按照第一個字段排序。對于在第一個字段上取值相同的記錄，系統再按照第二個字段的取值排序，以此類推。因此只有復合索引的第一個字段出現在查詢條件中，該索引才可能被使用,因此將應用頻度高的字段，放置在復合索引的前面，會使系統最大可能地使用此索引，發揮索引的作用。

4、如何創建索引

4.1?創建索引的語法：

CREATE?[UNIQUE][CLUSTERED?|?NONCLUSTERED]??INDEX??index_name??

ON?{table_name?|?view_name}?[WITH?[index_property?[,....n]]

說明：

UNIQUE:?建立唯一索引。

CLUSTERED:?建立聚集索引。

NONCLUSTERED:?建立非聚集索引。

Index_property:?索引屬性。

?UNIQUE索引既可以采用聚集索引結構，也可以采用非聚集索引的結構，如果不指明采用的索引結構，則SQL?Server系統默認為采用非聚集索引結構。

4.2?刪除索引語法：

DROP?INDEX?table_name.index_name[,table_name.index_name]

說明：table_name:?索引所在的表名稱。

index_name?:?要刪除的索引名稱。

4.3?顯示索引信息：

使用系統存儲過程：sp_helpindex?查看指定表的索引信息。

執行代碼如下：

Exec?sp_helpindex?book1;

5、索引使用次數、索引效率、占用CPU檢測、索引缺失

　　當我們明白了什么是索引，什么時間創建索引以后，我們就會想，我們創建的索引到底效率執行的怎么樣？好不好？我們創建的對不對？

　　首先我們來認識一下DMV，DMV?(dynamic?management?view)動態管理視圖和函數返回特定于實現的內部狀態數據。推出SQL?Server?2005時，微軟介紹了許多被稱為dmvs的系統視圖，讓您可以探測SQL?Server?的健康狀況，診斷問題，或查看SQL?Server實例的運行信息。統計數據是在SQL?Server運行的時候開始收集的，并且在SQL?Server每次啟動的時候，統計數據將會被重置。當你刪除或者重新創建其組件時，某些dmv的統計數據也可以被重置，例如存儲過程和表，而其它的dmv信息在運行dbcc命令時也可以被重置。

　　當你使用一個dmv時，你需要緊記SQL?Server收集這些信息有多長時間了，以確定這些從dmv返回的數據到底有多少可用性。如果SQL?Server只運行了很短的一段時間，你可能不想去使用一些dmv統計數據，因為他們并不是一個能夠代表SQL?Server實例可能遇到的真實工作負載的樣本。另一方面，SQL?Server只能維持一定量的信息，有些信息在進行SQL?Server性能管理活動的時候可能丟失，所以如果SQL?Server已經運行了相當長的一段時間，一些統計數據就有可能已被覆蓋。

　　因此，任何時候你使用dmv，當你查看從SQL?Server?2005的dmvs返回的相關資料時，請務必將以上的觀點裝在腦海中。只有當你確信從dmvs獲得的信息是準確和完整的，你才能變更數據庫或者應用程序代碼。

下面就看一下dmv到底能帶給我們那些好的功能呢？

5.1?：索引使用次數

我們下看一下下面兩種查詢方式返回的結果（這兩種查詢的查詢用途一致）

①----

declare?@dbid?intselect?@dbid?=?db_id()select?objectname=object_name(s.object_id),?s.object_id,?indexname=i.name,?i.index_id,?user_seeks,?user_scans,?user_lookups,?user_updatesfrom?sys.dm_db_index_usage_stats?s,sys.indexes?iwhere?database_id?=?@dbid?and?objectproperty(s.object_id,'IsUserTable')?=?1and?i.object_id?=?s.object_idand?i.index_id?=?s.index_idorder?by?(user_seeks?+?user_scans?+?user_lookups?+?user_updates)?asc

返回查詢結果:

②：使用多的索引排在前面

SELECT??objects.name?,databases.name?,indexes.name?,user_seeks?,user_scans?,user_lookups?,partition_stats.row_countFROM????sys.dm_db_index_usage_stats?statsLEFT?JOIN?sys.objects?objects?ON?stats.object_id?=?objects.object_idLEFT?JOIN?sys.databases?databases?ON?databases.database_id?=?stats.database_idLEFT?JOIN?sys.indexes?indexes?ON?indexes.index_id?=?stats.index_idAND?stats.object_id?=?indexes.object_idLEFT??JOIN?sys.dm_db_partition_stats?partition_stats?ON?stats.object_id?=?partition_stats.object_idAND?indexes.index_id?=?partition_stats.index_idWHERE???1?=?1--AND?databases.database_id?=?7AND?objects.name?IS?NOT?NULLAND?indexes.name?IS?NOT?NULLAND?user_scans>0ORDER?BY?user_scans?DESC?,stats.object_id?,indexes.index_id

返回查詢結果:

user_seeks?:?通過用戶查詢執行的搜索次數。?
?個人理解：?此統計索引搜索的次數

user_scans:?通過用戶查詢執行的掃描次數。?
? 個人理解：此統計表掃描的次數，無索引配合
user_lookups:?通過用戶查詢執行的查找次數。?
?個人理解：用戶通過索引查找，在使用RID或聚集索引查找數據的次數，對于堆表或聚集表數據而言和索引配合使用次數
user_updates:??通過用戶查詢執行的更新次數。?
? 個人理解：索引或表的更新次數

我們可以清晰的看到，那些索引用的多，那些索引沒用過，大家可以根據查詢出來的東西去分析自己的數據索引和表

5.2? 索引提高了多少性能

新建了索引到底增加了多少數據的效率呢？到底提高了多少性能呢？運行如下SQL可以返回連接缺失索引動態管理視圖，發現最有用的索引和創建索引的方法：?

SELECT avg_user_impact AS average_improvement_percentage, avg_total_user_cost AS average_cost_of_query_without_missing_index, 'CREATE INDEX ix_' + [statement] + ISNULL(equality_columns, '_') + ISNULL(inequality_columns, '_') + ' ON ' + [statement] + ' (' + ISNULL(equality_columns, ' ') + ISNULL(inequality_columns, ' ') + ')' + ISNULL(' INCLUDE (' + included_columns + ')', '') AS create_missing_index_command FROM sys.dm_db_missing_index_details a INNER JOIN sys.dm_db_missing_index_groups b ON a.index_handle = b.index_handle INNER JOIN sys.dm_db_missing_index_group_stats c ON b.index_group_handle = c.group_handle WHERE avg_user_impact > = 40

返回結果:

雖然用戶能夠修改性能提高的百分比，但以上查詢返回所有能夠將性能提高40%或更高的索引。你可以清晰的看到每個索引提高的性能和效率了

5.3? 最占用CPU、執行時間最長命令

這個和索引無關，但是還是在這里提出來，因為他也屬于DMV帶給我們的功能嗎，他可以讓你輕松查詢出，那些sql語句占用你的cpu最高

SELECT TOP 100 execution_count,total_logical_reads /execution_count AS [Avg Logical Reads],total_elapsed_time /execution_count AS [Avg Elapsed Time],db_name(st.dbid) as [database name],object_name(st.dbid) as [object name],object_name(st.objectid) as [object name 1],SUBSTRING(st.text, (qs.statement_start_offset / 2) + 1, ((CASE statement_end_offset WHEN - 1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset) / 2) + 1) AS statement_textFROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS stWHERE execution_count > 100ORDER BY 1 DESC;

執行時間最長的命令:

SELECT TOP 10 COALESCE(DB_NAME(st.dbid),DB_NAME(CAST(pa.value as int))+'*','Resource') AS DBNAME,SUBSTRING(text,-- starting value for substringCASE WHEN statement_start_offset = 0OR statement_start_offset IS NULLTHEN 1ELSE statement_start_offset/2 + 1 END,-- ending value for substringCASE WHEN statement_end_offset = 0OR statement_end_offset = -1OR statement_end_offset IS NULLTHEN LEN(text)ELSE statement_end_offset/2 END -CASE WHEN statement_start_offset = 0OR statement_start_offset IS NULLTHEN 1ELSE statement_start_offset/2 END + 1) AS TSQL,total_logical_reads/execution_count AS AVG_LOGICAL_READSFROM sys.dm_exec_query_statsCROSS APPLY sys.dm_exec_sql_text(sql_handle) stOUTER APPLY sys.dm_exec_plan_attributes(plan_handle) paWHERE attribute = 'dbid'ORDER BY AVG_LOGICAL_READS DESC ;

查詢結果：

看到了嗎？直接可以定位到你的sql語句，優化去吧。還等什么呢？

5.4 缺失索引

缺失索引就是幫你查找你的數據庫缺少什么索引，告訴你那些字段需要加上索引，這樣你就可以根據提示添加你數據庫缺少的索引了

SELECT TOP 10[Total Cost] = ROUND(avg_total_user_cost * avg_user_impact * (user_seeks + user_scans),0), avg_user_impact, TableName = statement, [EqualityUsage] = equality_columns, [InequalityUsage] = inequality_columns, [Include Cloumns] = included_columnsFROM sys.dm_db_missing_index_groups gINNER JOIN sys.dm_db_missing_index_group_stats sON s.group_handle = g.index_group_handleINNER JOIN sys.dm_db_missing_index_details dON d.index_handle = g.index_handleORDER BY [Total Cost] DESC;

查詢結果如下：

6??適當創建索引覆蓋

假設你在Sales表(SelesID,SalesDate,SalesPersonID,ProductID,Qty)的外鍵列(ProductID)上創建了一個索引，假設ProductID列是一個高選中性列，那么任何在where子句中使用索引列(ProductID)的select查詢都會更快，如果在外鍵上沒有創建索引，將會發生全部掃描，但還有辦法可以進一步提升查詢性能。

　　假設Sales表有10,000行記錄，下面的SQL語句選中400行(總行數的4%)：　

SELECT SalesDate, SalesPersonID FROM Sales WHERE ProductID = 112

我們來看看這條SQL語句在SQL執行引擎中是如何執行的：

　　1)Sales表在ProductID列上有一個非聚集索引，因此它查找非聚集索引樹找出ProductID=112的記錄;

　　2)包含ProductID?=?112記錄的索引頁也包括所有的聚集索引鍵(所有的主鍵鍵值，即SalesID);

　　3)針對每一個主鍵(這里是400)，SQL?Server引擎查找聚集索引樹找出真實的行在對應頁面中的位置;

　　SQL?Server引擎從對應的行查找SalesDate和SalesPersonID列的值。

　　在上面的步驟中，對ProductID?=?112的每個主鍵記錄(這里是400)，SQL?Server引擎要搜索400次聚集索引樹以檢索查詢中指定的其它列(SalesDate，SalesPersonID)。

　　如果非聚集索引頁中包括了聚集索引鍵和其它兩列(SalesDate,，SalesPersonID)的值，SQL?Server引擎可能不會執行上面的第3和4步，直接從非聚集索引樹查找ProductID列速度還會快一些，直接從索引頁讀取這三列的數值。

　　幸運的是，有一種方法實現了這個功能，它被稱為“覆蓋索引”，在表列上創建覆蓋索引時，需要指定哪些額外的列值需要和聚集索引鍵值(主鍵)一起存儲在索引頁中。下面是在Sales?表ProductID列上創建覆蓋索引的例子：　

CREATE?INDEX?NCLIX_Sales_ProductID--Index?name

　　ON?dbo.Sales(ProductID)--Column?on?which?index?is?to?be?created
　　INCLUDE(SalesDate,?SalesPersonID)--Additional?column?values?to?include

　　應該在那些select查詢中常使用到的列上創建覆蓋索引，但覆蓋索引中包括過多的列也不行，因為覆蓋索引列的值是存儲在內存中的，這樣會消耗過多內存，引發性能下降。

7、索引碎片

如果你的表已經創建好了索引，但性能卻仍然不好，那很可能是產生了索引碎片，你需要進行索引碎片整理。

　　什么是索引碎片?

　　由于表上有過度地插入、修改和刪除操作，索引頁被分成多塊就形成了索引碎片，如果索引碎片嚴重，那掃描索引的時間就會變長，甚至導致索引不可用，因此數據檢索操作就慢下來了。

　　如何知道是否發生了索引碎片?

在SQLServer數據庫，通過DBCC?ShowContig或DBCC?ShowContig(表名)檢查索引碎片情況，指導我們對其進行定時重建整理。?

通過對掃描密度（過低），掃描碎片（過高）的結果分析，判定是否需要索引重建，主要看如下兩個：
Scan?Density?[Best?Count:Actual?Count]-掃描密度［最佳值:實際值］：DBCC?SHOWCONTIG返回最有用的一個百分比。這是擴展盤區的最佳值和實際值的比率。該百分比應該盡可能靠近100％。低了則說明有外部碎片。

Logical?Scan?Fragmentation-邏輯掃描碎片：無序頁的百分比。該百分比應該在0％到10％之間，高了則說明有外部碎片。?

解決方式：

一是利用DBCC?INDEXDEFRAG整理索引碎片

二是利用DBCC?DBREINDEX重建索引。

兩者區別調用微軟的原話如下：
DBCC?INDEXDEFRAG?命令是聯機操作，所以索引只有在該命令正在運行時才可用，而且可以在不丟失已完成工作的情況下中斷該操作。這種方法的缺點是在重新組織數據方面沒有聚集索引的除去/重新創建操作有效。
重新創建聚集索引將對數據進行重新組織，其結果是使數據頁填滿。填滿程度可以使用?FILLFACTOR?選項進行配置。這種方法的缺點是索引在除去/重新創建周期內為脫機狀態，并且操作屬原子級。如果中斷索引創建，則不會重新創建該索引。也就是說，要想獲得好的效果，還是得用重建索引，所以決定重建索引。

8、索引實戰

人們在使用SQL時往往會陷入一個誤區，即太關注于所得的結果是否正確，而忽略了不同的實現方法之間可能存在的性能差異，這種性能差異在大型的或是復雜的數據庫環境中（如聯機事務處理OLTP或決策支持系統DSS）中表現得尤為明顯。

筆者在工作實踐中發現，不良的SQL往往來自于不恰當的索引設計、不充份的連接條件和不可優化的where子句。

在對它們進行適當的優化后，其運行速度有了明顯地提高！

下面我將從這三個方面分別進行總結：

為了更直觀地說明問題，所有實例中的SQL運行時間均經過測試，不超過１秒的均表示為（<?1秒）。----

測試環境:?主機：HP?LH?II----?主頻：330MHZ----?內存：128兆----

操作系統：Operserver5.0.4----

數據庫：Sybase11.0.3

一、不合理的索引設計----

例：表record有620000行，試看在不同的索引下，下面幾個?SQL的運行情況：

----?1.在date上建有一非個群集索引

select?count(*)?from?record?where?date?>'19991201'?and?date?<?'19991214'and?amount?>2000?(25秒)

select?date?,sum(amount)?from?record?group?by?date(55秒)

select?count(*)?from?record?where?date?>'19990901'?and?place?in?('BJ','SH')?(27秒)

----?分析：----

date上有大量的重復值，在非群集索引下，數據在物理上隨機存放在數據頁上，在范圍查找時，必須執行一次表掃描才能找到這一范圍內的全部行。

----?2.在date上的一個群集索引

select?count(*)?from?record?where?date?>'19991201'?and?date?<?'19991214'?and?amount?>2000?（14秒）

select?date,sum(amount)?from?record?group?by?date（28秒）

select?count(*)?from?record?where?date?>'19990901'?and?place?in?('BJ','SH')（14秒）

----?分析：----?在群集索引下，數據在物理上按順序在數據頁上，重復值也排列在一起，因而在范圍查找時，可以先找到這個范圍的起末點，且只在這個范圍內掃描數據頁，避免了大范圍掃描，提高了查詢速度。

----?3.在place，date，amount上的組合索引

select?count(*)?from?record?where?date?>'19991201'?and?date?<?'19991214'?and?amount?>2000?（26秒）

select?date,sum(amount)?from?record?group?by?date（27秒）

select?count(*)?from?record?where?date?>'19990901'?and?place?in?('BJ,?'SH')（<?1秒）

----?分析：----?這是一個不很合理的組合索引，因為它的前導列是place，第一和第二條SQL沒有引用place，因此也沒有利用上索引；第三個SQL使用了place，且引用的所有列都包含在組合索引中，形成了索引覆蓋，所以它的速度是非常快的。

----?4.在date，place，amount上的組合索引

select?count(*)?from?record?where?date?>'19991201'?and?date?<?'19991214'?and?amount?>2000(<?1秒)

select?date,sum(amount)?from?record?group?by?date（11秒）

select?count(*)?from?record?where?date?>'19990901'?and?place?in?('BJ','SH')（<?1秒）

----?分析：----?這是一個合理的組合索引。它將date作為前導列，使每個SQL都可以利用索引，并且在第一和第三個SQL中形成了索引覆蓋，因而性能達到了最優。

----?5.總結：----

缺省情況下建立的索引是非群集索引，但有時它并不是最佳的；合理的索引設計要建立在對各種查詢的分析和預測上。

一般來說：

①.有大量重復值、且經常有范圍查詢（between,?>,<?，>=,<?=）和order?by、group?by發生的列，可考慮建立群集索引；

②.經常同時存取多列，且每列都含有重復值可考慮建立組合索引；

③.組合索引要盡量使關鍵查詢形成索引覆蓋，其前導列一定是使用最頻繁的列。

?

二、不充份的連接條件：

例：表card有7896行，在card_no上有一個非聚集索引，表account有191122行，在account_no上有一個非聚集索引，試看在不同的表連接條件下，兩個SQL的執行情況：

select?sum(a.amount)?from?account?a,card?b?where?a.card_no?=?b.card_no（20秒）

select?sum(a.amount)?from?account?a,card?b?where?a.card_no?=?b.card_no?and?a.account_no=b.account_no（<?1秒）

----?分析：----?在第一個連接條件下，最佳查詢方案是將account作外層表，card作內層表，利用card上的索引，其I/O次數可由以下公式估算為：

外層表account上的22541頁+（外層表account的191122行*內層表card上對應外層表第一行所要查找的3頁）=595907次I/O

在第二個連接條件下，最佳查詢方案是將card作外層表，account作內層表，利用account上的索引，其I/O次數可由以下公式估算為：外層表card上的1944頁+（外層表card的7896行*內層表account上對應外層表每一行所要查找的4頁）=?33528次I/O

可見，只有充份的連接條件，真正的最佳方案才會被執行。

總結：

1.多表操作在被實際執行前，查詢優化器會根據連接條件，列出幾組可能的連接方案并從中找出系統開銷最小的最佳方案。連接條件要充份考慮帶有索引的表、行數多的表；內外表的選擇可由公式：外層表中的匹配行數*內層表中每一次查找的次數確定，乘積最小為最佳方案。

2.查看執行方案的方法--?用set?showplanon，打開showplan選項，就可以看到連接順序、使用何種索引的信息；想看更詳細的信息，需用sa角色執行dbcc(3604,310,302)。

?

三、不可優化的where子句

1.例：下列SQL條件語句中的列都建有恰當的索引，但執行速度卻非常慢：

select?*?from?record?wheresubstring(card_no,1,4)='5378'(13秒)

select?*?from?record?whereamount/30<?1000（11秒）

select?*?from?record?whereconvert(char(10),date,112)='19991201'（10秒）

分析：

where子句中對列的任何操作結果都是在SQL運行時逐列計算得到的，因此它不得不進行表搜索，而沒有使用該列上面的索引；

如果這些結果在查詢編譯時就能得到，那么就可以被SQL優化器優化，使用索引，避免表搜索，因此將SQL重寫成下面這樣：

select?*?from?record?where?card_no?like'5378%'（<?1秒）

select?*?from?record?where?amount<?1000*30（<?1秒）

select?*?from?record?where?date=?'1999/12/01'（<?1秒）

你會發現SQL明顯快起來！

2.例：表stuff有200000行，id_no上有非群集索引，請看下面這個SQL：

select?count(*)?from?stuff?where?id_no?in('0','1')（23秒）

分析：----?where條件中的'in'在邏輯上相當于'or'，所以語法分析器會將in?('0','1')轉化為id_no?='0'?or?id_no='1'來執行。

我們期望它會根據每個or子句分別查找，再將結果相加，這樣可以利用id_no上的索引；

但實際上（根據showplan）,它卻采用了"OR策略"，即先取出滿足每個or子句的行，存入臨時數據庫的工作表中，再建立唯一索引以去掉重復行，最后從這個臨時表中計算結果。因此，實際過程沒有利用id_no上索引，并且完成時間還要受tempdb數據庫性能的影響。

實踐證明，表的行數越多，工作表的性能就越差，當stuff有620000行時，執行時間竟達到220秒！還不如將or子句分開：

select?count(*)?from?stuff?where?id_no='0'select?count(*)?from?stuff?where?id_no='1'

得到兩個結果，再作一次加法合算。因為每句都使用了索引，執行時間只有3秒，在620000行下，時間也只有4秒。

或者，用更好的方法，寫一個簡單的存儲過程：

create?proc?count_stuff?asdeclare?@a?intdeclare?@b?intdeclare?@c?intdeclare?@d?char(10)beginselect?@a=count(*)?from?stuff?where?id_no='0'select?@b=count(*)?from?stuff?where?id_no='1'endselect?@c=@a+@bselect?@d=convert(char(10),@c)print?@d

直接算出結果，執行時間同上面一樣快！

9、總結：

可見，所謂優化即where子句利用了索引，不可優化即發生了表掃描或額外開銷。

1.任何對列的操作都將導致表掃描，它包括數據庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。

2.in、or子句常會使用工作表，使索引失效；如果不產生大量重復值，可以考慮把子句拆開；拆開的子句中應該包含索引。

3.要善于使用存儲過程，它使SQL變得更加靈活和高效。

從以上這些例子可以看出，SQL優化的實質就是在結果正確的前提下，用優化器可以識別的語句，充份利用索引，減少表掃描的I/O次數，盡量避免表搜索的發生。其實SQL的性能優化是一個復雜的過程，上述這些只是在應用層次的一種體現，深入研究還會涉及數據庫層的資源配置、網絡層的流量控制以及操作系統層的總體設計。

?

希望能對大家有所幫助。

總結

以上是生活随笔為你收集整理的SQL基础【二十、索引】(超细致版本，前理论，后实践，应对sql面试绰绰有余)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。