SQL索引



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

1.1 什麼是索引？

　　SQL索引有兩種，彙集索引和非彙集索引，索引主要目的是提升了SQL Server系統的性能，加快數據的查詢速度與下降系統的響應時間 

如下舉兩個簡單的樣例：

圖書館的樣例：一個圖書館那麼多書，怎麼管理呢？創建一個字母開頭的文件夾，好比：a開頭的書，在第一排，b開頭的在第二排，這樣在找什麼書就好說了，這個就是一個彙集索引，可是很是多人借書找某某做者的，不知道書名怎麼辦？圖書管理員在寫一個文件夾，某某做者的書分別在第幾排，第幾排。這就是一個非彙集索引

字典的樣例：字典前面的文件夾，可以依照拼音和部首去查詢，咱們想查詢一個字，僅僅需要依據拼音或者部首去查詢。就可以高速的定位到這個漢字了，這個就是索引的優勢，拼音查詢法就是彙集索引，部首查詢就是一個非彙集索引.

    看了上面的樣例，如下的一句話你們就很是easy理解了：彙集索引存儲記錄是物理上連續存在，而非彙集索引是邏輯上的連續，物理存儲並不連續。就像字段。彙集索引是連續的，a後面確定是b，非彙集索引就不連續了。就像圖書館的某個做者的書，有可能在第1個貨架上和第10個貨架上。另外一個小知識點就是：彙集索引一個表僅僅能有一個，而非彙集索引一個表可以存在多個。

　

1.2 索引的存儲機制

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

       彙集索引和非彙集索引的根本差異是表記錄的排列順序和與索引的排列順序是否一致，事實上理解起來很easy。仍是舉字典的樣例：假設依照拼音查詢，那麼都是從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) 經常出現在keywordorder by、group by、distinct後面的字段，創建索引。假設創建的是複合索引，索引的字段順序要和這些keyword後面的字段順序一致。不然索引不會被使用。

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 : 經過用戶查詢運行的搜索次數。

 
 我的理解： 此統計索引搜索的次數

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

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 where substring(card_no,1,4)='5378'(13秒)

select * from record where amount/30< 1000（11秒）

select * from record where convert(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)
begin
select @a=count(*) from stuff where id_no='0'
select @b=count(*) from stuff where id_no='1'
end
select @c=@a+@b
select @d=convert(char(10),@c)
print @d

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

 

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

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

2.in、or子句常會使用工做表。使索引失效；假設不產生大量反覆值，可以考慮把子句拆開；拆開的子句中應該包括索引。

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

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