強烈推薦|關於 SQL 索引講的非常全的一篇文章

SQL索引在資料庫最佳化中佔有一個非常大的比例， 一個好的索引的設計，可以讓你的效率提高幾十甚至幾百倍，在這裡將帶你一步步揭開他的神秘面紗。

什麼是索引？

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

下麵舉兩個簡單的例子：

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

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

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

1.2 索引的儲存機制

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

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

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

什麼情況下設定索引

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

建立索引的原則：

• 1) 定義主鍵的資料列一定要建立索引。
• 2) 定義有外來鍵的資料列一定要建立索引。
• 3) 對於經常查詢的資料列最好建立索引。
• 4) 對於需要在指定範圍內的快速或頻繁查詢的資料列;
• 5) 經常用在WHERE子句中的資料列。
• 6) 經常出現在關鍵字order by、group by、distinct後面的欄位，建立索引。如果建立的是複合索引，索引的欄位順序要和這些關鍵字後面的欄位順序一致，否則索引不會被使用。
• 7) 對於那些查詢中很少涉及的列，重覆值比較多的列不要建立索引。
• 8) 對於定義為text、image和bit的資料型別的列不要建立索引。
• 9) 對於經常存取的列避免建立索引 
• 10) 限製表上的索引數目。對一個存在大量更新操作的表，所建索引的數目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響資料的更新操作。
• 11) 對複合索引，按照欄位在查詢條件中出現的頻度建立索引。在複合索引中，記錄首先按照第一個欄位排序。對於在第一個欄位上取值相同的記錄，系統再按照第二個欄位的取值排序，以此類推。因此只有複合索引的第一個欄位出現在查詢條件中，該索引才可能被使用,因此將應用頻度高的欄位，放置在複合索引的前面，會使系統最大可能地使用此索引，發揮索引的作用。

1.4 如何建立索引

1.41 建立索引的語法：

1. CREATE [UNIQUE][CLUSTERED | NONCLUSTERED]  INDEX  index_name  
3. ON {table_name | view_name} [WITH [index_property [,....n]]

說明：

UNIQUE: 建立唯一索引。

CLUSTERED: 建立聚集索引。

NONCLUSTERED: 建立非聚集索引。

Index_property: 索引屬性。

 UNIQUE索引既可以採用聚集索引結構，也可以採用非聚集索引的結構，如果不指明採用的索引結構，則SQL Server系統預設為採用非聚集索引結構。

1.42 刪除索引語法：

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

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

index_name : 要刪除的索引名稱。

1.43 顯示索引資訊：

使用系統儲存過程：sp_helpindex 檢視指定表的索引資訊。

執行程式碼如下：

1. Exec sp_helpindex book1;

1.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到底能帶給我們那些好的功能呢？

1.51 ：索引使用次數

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

①—-

1. declare @dbid int
3. select @dbid = db_id()
5. select objectname=object_name(s.object_id), s.object_id, indexname=i.name, i.index_id
7.      , user_seeks, user_scans, user_lookups, user_updates
9. from sys.dm_db_index_usage_stats s,
11.      sys.indexes i
13. where database_id = @dbid and objectproperty(s.object_id,'IsUserTable') = 1
15. and i.object_id = s.object_id
17. and i.index_id = s.index_id
19. order by (user_seeks + user_scans + user_lookups + user_updates) asc

傳回查詢結果

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

1. SELECT  objects.name ,
3.  databases.name ,
5.  indexes.name ,
7.  user_seeks ,
9.  user_scans ,
11.  user_lookups ,
13.  partition_stats.row_count
15. FROM    sys.dm_db_index_usage_stats stats
17.  LEFT JOIN sys.objects objects ON stats.object_id = objects.object_id
19.  LEFT JOIN sys.databases databases ON databases.database_id = stats.database_id
21.  LEFT JOIN sys.indexes indexes ON indexes.index_id = stats.index_id
23. AND stats.object_id = indexes.object_id
25.  LEFT  JOIN sys.dm_db_partition_stats partition_stats ON stats.object_id = partition_stats.object_id
27. AND indexes.index_id = partition_stats.index_id
29. WHERE   1 = 1
31. --AND databases.database_id = 7
33.  AND objects.name IS NOT NULL
35.  AND indexes.name IS NOT NULL
37.  AND user_scans>0
39. ORDER BY user_scans DESC ,
41.  stats.object_id ,
43.  indexes.index_id

傳回查詢結果

user_seeks : 透過使用者查詢執行的搜尋次數。

個人理解： 此統計索引搜尋的次數

user_scans: 透過使用者查詢執行的掃描次數。

個人理解：此統計表掃描的次數，無索引配合

user_lookups: 透過使用者查詢執行的查詢次數。

個人理解：使用者透過索引查詢，在使用RID或聚集索引查詢資料的次數，對於堆表或聚集表資料而言和索引配合使用次數

user_updates:  透過使用者查詢執行的更新次數。

  個人理解：索引或表的更新次數

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

1.52 ：索引提高了多少效能

新建了索引到底增加了多少資料的效率呢？到底提高了多少效能呢？執行如下SQL可以傳回連線缺失索引動態管理檢視，發現最有用的索引和建立索引的方法：

1. SELECT  
3. avg_user_impact AS average_improvement_percentage,  
5. avg_total_user_cost AS average_cost_of_query_without_missing_index,  
7. 'CREATE INDEX ix_' + [statement] +  
9. ISNULL(equality_columns, '_') + 
11. ISNULL(inequality_columns, '_') + ' ON ' + [statement] +  
13. ' (' + ISNULL(equality_columns, ' ') +  
15. ISNULL(inequality_columns, ' ') + ')' +  
17. ISNULL(' INCLUDE (' + included_columns + ')', '')  
19. AS create_missing_index_command 
21. FROM sys.dm_db_missing_index_details a INNER JOIN  
23. sys.dm_db_missing_index_groups b ON a.index_handle = b.index_handle 
25. INNER JOIN sys.dm_db_missing_index_group_stats c ON  
27. b.index_group_handle = c.group_handle 
29. WHERE avg_user_impact > = 40

傳回結果

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

1.53 ：最佔用CPU、執行時間最長命令

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

1. SELECT TOP 100 execution_count,
3.     total_logical_reads /execution_count AS [Avg Logical Reads],
5.     total_elapsed_time /execution_count AS [Avg Elapsed Time],
7.   db_name(st.dbid) as [database name],
9.     object_name(st.dbid) as [object name],
11.     object_name(st.objectid) as [object name 1],
13.     SUBSTRING(st.text, (qs.statement_start_offset / 2) + 1, 
15.     ((CASE statement_end_offset WHEN - 1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset) 
17. / 2) + 1) AS statement_text
19.   FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
21.  WHERE execution_count > 100
23.  ORDER BY 1 DESC;

傳回結果：

執行時間最長的命令

1. SELECT TOP 10 COALESCE(DB_NAME(st.dbid),
3. DB_NAME(CAST(pa.value as int))+'*',
5. 'Resource') AS DBNAME,
7. SUBSTRING(text,
9. -- starting value for substring
11.  CASE WHEN statement_start_offset = 0
13. OR statement_start_offset IS NULL
15. THEN 1
17. ELSE statement_start_offset/2 + 1 END,
19. -- ending value for substring
21.  CASE WHEN statement_end_offset = 0
23. OR statement_end_offset = -1
25. OR statement_end_offset IS NULL
27. THEN LEN(text)
29. ELSE statement_end_offset/2 END -
31. CASE WHEN statement_start_offset = 0
33. OR statement_start_offset IS NULL
35. THEN 1
37. ELSE statement_start_offset/2  END + 1
39. )  AS TSQL,
41. total_logical_reads/execution_count AS AVG_LOGICAL_READS
43. FROM sys.dm_exec_query_stats
45. CROSS APPLY sys.dm_exec_sql_text(sql_handle) st
47. OUTER APPLY sys.dm_exec_plan_attributes(plan_handle) pa
49. WHERE attribute = 'dbid'
51. ORDER BY AVG_LOGICAL_READS DESC ;

看到了嗎？直接可以定位到你的sql陳述句，最佳化去吧。還等什麼呢？

v1.54：缺失索引

缺失索引就是幫你查詢你的資料庫缺少什麼索引，告訴你那些欄位需要加上索引，這樣你就可以根據提示新增你資料庫缺少的索引了

1. SELECT TOP 10
3. [Total Cost] = ROUND(avg_total_user_cost * avg_user_impact * (user_seeks + user_scans),0)
5. , avg_user_impact
7. , TableName = statement
9. , [EqualityUsage] = equality_columns
11. , [InequalityUsage] = inequality_columns
13. , [Include Cloumns] = included_columns
15. FROM    sys.dm_db_missing_index_groups g
17. INNER JOIN sys.dm_db_missing_index_group_stats s
19. ON s.group_handle = g.index_group_handle
21. INNER JOIN sys.dm_db_missing_index_details d
23. ON d.index_handle = g.index_handle
25. ORDER BY [Total Cost] DESC;

查詢結果如下：

1.6  適當建立索引改寫

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

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

1. 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列上建立改寫索引的例子：

1. CREATE INDEX NCLIX_Sales_ProductID--Index name
3. ON dbo.Sales(ProductID)--Column on which index is to be created
4. INCLUDE(SalesDate, SalesPersonID)--Additional column values to include

應該在那些select查詢中常使用到的列上建立改寫索引，但改寫索引中包括過多的列也不行，因為改寫索引列的值是儲存在記憶體中的，這樣會消耗過多記憶體，引發效能下降。

1.7 索引碎片

在資料庫效能最佳化一：資料庫自身最佳化一文中已經講到了這個問題，再次就不做過多的重覆地址：http://www.cnblogs.com/AK2012/archive/2012/12/25/2012-1228.html

1.8 索引實戰（摘抄）

之所以這章摘抄，是因為下麵這個文章已經寫的太好了，估計我寫出來也無法比這個好了，所以就摘抄了

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

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

在對它們進行適當的最佳化後，其執行速度有了明顯地提高！

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

為了更直觀地說明問題，所有實體中的SQL執行時間均經過測試，不超過１秒的均表示為（

測試環境: 主機：HP LH II—- 主頻：330MHZ—- 記憶體：128兆—-

作業系統：Operserver5.0.4—-

資料庫：Sybase11.0.3

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

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

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

1. select count(*) from record where date >'19991201' and date '19991214'and amount >2000 (25秒)
3. select date ,sum(amount) from record group by date(55秒)
5. select count(*) from record where date >'19990901' and place in ('BJ','SH') (27秒)

—- 分析：—-

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

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

1. select count(*) from record where date >'19991201' and date '19991214' and amount >2000 （14秒）
3. select date,sum(amount) from record group by date（28秒）
5. select count(*) from record where date >'19990901' and place in ('BJ','SH')（14秒）

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

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

1. select count(*) from record where date >'19991201' and date '19991214' and amount >2000 （26秒）
3. select date,sum(amount) from record group by date（27秒）
5. select count(*) from record where date >'19990901' and place in ('BJ, 'SH')（

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

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

1. select count(*) from record where date >'19991201' and date '19991214' and amount >2000(1秒)
3. select date,sum(amount) from record group by date（11秒）
5. select count(*) from record where date >'19990901' and place in ('BJ','SH')（1秒）

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

—- 5.總結：—-

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

一般來說：

①.有大量重覆值、且經常有範圍查詢（between, >,=,

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

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

二、不充份的連線條件：

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

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

select sum(a.amount) from account a,card b where a.cardno = b.cardno and a.accountno=b.accountno（

—- 分析：—- 在第一個連線條件下，最佳查詢方案是將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條件陳述句中的列都建有恰當的索引，但執行速度卻非常慢：

1. select * from record wheresubstring(card_no,1,4)='5378'(13秒)
3. select * from record whereamount/301000（11秒）
5. select * from record whereconvert(char(10),date,112)='19991201'（10秒）

分析：

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

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

1. select * from record where card_no like'5378%'（1秒）
3. select * from record where amount1000*30（1秒）
5. select * from record where date= '1999/12/01'（1秒）

你會發現SQL明顯快起來！

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

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

分析：—- where條件中的’in’在邏輯上相當於’or’，所以語法分析器會將in (‘0′,’1′)轉化為idno =’0’ or idno=’1’來執行。

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

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

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

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

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

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

1. 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

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

—- 總結：—- 可見，所謂最佳化即where子句利用了索引，不可最佳化即發生了表掃描或額外開銷。

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

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

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

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

1.7索引實戰是摘抄網友的文章，取用地址：http://blog.csdn.net/gprime/article/details/1687930