數據庫性能優化：SQL索引

SQL索引在數據庫優化中佔有一個很是大的比例， 一個好的索引的設計，可讓你的效率提升幾十甚至幾百倍，在這裏將帶你一步步揭開他的神祕面紗。

　　1.1 什麼是索引？

　　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，因此當插入數據時，他會從新排列整個整個物理空間，而非彙集索引其實能夠看做是一個含有彙集索引的表，他只僅包含原表中非彙集索引的列和指向實際物理表的指針。他只記錄一個指針，其實就有點和堆棧差很少的感受了

 

　　1.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) 對複合索引，按照字段在查詢條件中出現的頻度創建索引。在複合索引中，記錄首先按照第一個字段排序。對於在第一個字段上取值相同的記錄，系統再按照第二個字段的取值排序，以此類推。所以只有複合索引的第一個字段出如今查詢條件中，該索引纔可能被使用,所以將應用頻度高的字段，放置在複合索引的前面，會使系統最大可能地使用此索引，發揮索引的做用。

 

　　1.4 如何建立索引

　　1.41 建立索引的語法：

CREATE [UNIQUE][CLUSTERED | NONCLUSTERED]  INDEX  index_name 

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

說明：

UNIQUE: 創建惟一索引。

CLUSTERED: 創建彙集索引。

NONCLUSTERED: 創建非彙集索引。

Index_property: 索引屬性。

UNIQUE索引既能夠採用彙集索引結構，也能夠採用非彙集索引的結構，若是不指明採用的索引結構，則SQL Server系統默認爲採用非彙集索引結構。

1.42 刪除索引語法：

DROP INDEX table_name.index_name[,table_name.index_name]

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

index_name : 要刪除的索引名稱。

1.43 顯示索引信息：

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

執行代碼以下：

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 ：索引使用次數

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

①----

declare @dbid int

select @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_updates

from sys.dm_db_index_usage_stats s,

            sys.indexes i

where database_id = @dbid and objectproperty(s.object_id,'IsUserTable') = 1

and i.object_id = s.object_id

and i.index_id = s.index_id

order 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_count

FROM    sys.dm_db_index_usage_stats stats

        LEFT JOIN sys.objects objects ON stats.object_id = objects.object_id

        LEFT JOIN sys.databases databases ON databases.database_id = stats.database_id

        LEFT JOIN sys.indexes indexes ON indexes.index_id = stats.index_id

                                         AND stats.object_id = indexes.object_id

        LEFT  JOIN sys.dm_db_partition_stats partition_stats ON stats.object_id = partition_stats.object_id

                                                              AND indexes.index_id = partition_stats.index_id

WHERE   1 = 1

--AND databases.database_id = 7

        AND objects.name IS NOT NULL

        AND indexes.name IS NOT NULL

        AND user_scans>0

ORDER BY user_scans DESC ,

        stats.object_id ,

        indexes.index_id

返回查詢結果

 

user_seeks : 經過用戶查詢執行的搜索次數。 我的理解： 此統計索引搜索的次數

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

咱們能夠清晰的看到，那些索引用的多，那些索引沒用過，你們能夠根據查詢出來的東西去分析本身的數據索引和表

1.52 ：索引提升了多少性能

新建了索引到底增長了多少數據的效率呢？到底提升了多少性能呢？運行以下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%或更高的索引。你能夠清晰的看到每一個索引提升的性能和效率了

1.53 ：最佔用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_text

  FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st

WHERE execution_count > 100

ORDER 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 substring

        CASE WHEN statement_start_offset = 0

OR statement_start_offset IS NULL

THEN 1

ELSE statement_start_offset/2 + 1 END,

-- ending value for substring

        CASE WHEN statement_end_offset = 0

OR statement_end_offset = -1

OR statement_end_offset IS NULL

THEN LEN(text)

ELSE statement_end_offset/2 END -

CASE WHEN statement_start_offset = 0

OR statement_start_offset IS NULL

THEN 1

ELSE statement_start_offset/2  END + 1

)  AS TSQL,

total_logical_reads/execution_count AS AVG_LOGICAL_READS

FROM sys.dm_exec_query_stats

CROSS APPLY sys.dm_exec_sql_text(sql_handle) st

OUTER APPLY sys.dm_exec_plan_attributes(plan_handle) pa

WHERE attribute = 'dbid'

ORDER BY AVG_LOGICAL_READS DESC ;

 

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

1.54：缺失索引

缺失索引就是幫你查找你的數據庫缺乏什麼索引，告訴你那些字段須要加上索引，這樣你就能夠根據提示添加你數據庫缺乏的索引了

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_columns

FROM    sys.dm_db_missing_index_groups g

INNER JOIN sys.dm_db_missing_index_group_stats s

ON s.group_handle = g.index_group_handle

INNER JOIN sys.dm_db_missing_index_details d

ON d.index_handle = g.index_handle

ORDER BY [Total Cost] DESC;

查詢結果以下：

 

 

　　1.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查詢中常使用到的列上建立覆蓋索引，但覆蓋索引中包括過多的列也不行，由於覆蓋索引列的值是存儲在內存中的，這樣會消耗過多內存，引起性能降低。

　　

　　1.7 索引碎片

在數據庫性能優化一：數據庫自身優化一文中已經講到了這個問題，再次就不作過多的重複地址：http://www.cnblogs.com/AK2012/archive/2012/12/25/2012-1228.html

 

　　1.8 索引實戰（摘抄）

之因此這章摘抄，是由於下面這個文章已經寫的太好了，估計我寫出來也沒法比這個好了，因此就摘抄了

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

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

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

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

爲了更直觀地說明問題，全部實例中的SQL運行時間均通過測試，不超過１秒的均表示爲（< 1秒）。----

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

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

數據庫：Sybase11.0.3

 

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

例：表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發生的列，可考慮創建羣集索引；

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

③.組合索引要儘可能使關鍵查詢造成索引覆蓋，其前導列必定是使用最頻繁的列。

 

2、不充份的鏈接條件：

例：表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)。

 

3、不可優化的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

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

 

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

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

2.in、or子句常會使用工做表，使索引失效；若是不產生大量重複值，能夠考慮把子句拆開；拆開的子句中應該包含索引。

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

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

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