翻譯自： http://www.mssqltips.com/sqlservertip/2718/sql-server-index-column-order--does-it-matter/?utm_source=dailynewsletter&utm_medium=email&utm_content=headline&utm_campaign=2012619

問題：

當設(shè)置表的索引時，在性能上有一個微妙的平衡：太多的索引將影響你的INSERT/UPDATE/DELETE操作。但是索引不足又將影響你的SELECT操作。本文將著眼于索引的列順序和如何影響查詢計劃及性能。

解決方案：

示例SQLServer表和數(shù)據(jù)集：

-- Tablecreation logic

CREATE TABLE [dbo] . [TABLE1]

( [col1] [int] NOT NULL, [col2] [int] NULL, [col3] [int] NULL, [col4] [varchar] ( 50 ) NULL)

GO

CREATE TABLE [dbo] . [TABLE2]

( [col1] [int] NOT NULL, [col2] [int] NULL, [col3] [int] NULL, [col4] [varchar] ( 50 ) NULL)

GO

ALTER TABLE dbo . TABLE1 ADD CONSTRAINT PK_TABLE1 PRIMARY KEY CLUSTERED ( col1 )

GO

ALTER TABLE dbo . TABLE2 ADD CONSTRAINT PK_TABLE2 PRIMARY KEY CLUSTERED ( col1 )

GO

--Populate tables

DECLARE @val INT

SELECT @val = 1

WHILE @val < 1000

BEGIN ?

?? INSERT INTO dbo . Table1 ( col1 , col2 , col3 , col4 ) VALUES ( @val , @val , @val , 'TEST' )

?? INSERT INTO dbo . Table2 ( col1 , col2 , col3 , col4 ) VALUES ( @val , @val , @val , 'TEST' )

?? SELECT @val = @val + 1

END

GO

--Create multi-column index on table1

CREATE NONCLUSTERED INDEX IX_TABLE1_col2col3 ON dbo . TABLE1 ( col2 , col3 )

? WITH ( STATISTICS_NORECOMPUTE = OFF , IGNORE_DUP_KEY = OFF ,

??????? ALLOW_ROW_LOCKS = ON , ALLOW_PAGE_LOCKS = ON )

? ON [PRIMARY]

GO

在運行下面的代碼前請先打開執(zhí)行計劃（Ctrl+M）和打開統(tǒng)計IO的語句：SET STATISTICS IO ON

單表查詢例子：

在第一個例子里面，我們將使用在where子句中的一列來查詢。第一個查詢中where子句的索引使用第二列（col3），第二個查詢使用第一列（col2）。注意這里使用了“DBCC DROPCLEANBUFFERS”，用于確保沒有緩存帶來的影響，代碼如下：

DBCC DROPCLEANBUFFERS

GO

SELECT * FROM dbo.TABLE1 WHEREcol3=88

GO

DBCC DROPCLEANBUFFERS

GO

SELECT * FROM dbo.TABLE1 WHEREcol2=88

GO

執(zhí)行后查看執(zhí)行計劃如下：

可以看到，第一個查詢使用第二列（col3）的索引是在表上執(zhí)行索引掃描，且沒有用到剛才建立的索引。第二個查詢使用了表查找，使得在表里只需要使用更少的資源。第一個查詢讀了6次，而第二個查詢只讀了4次。

執(zhí)行查詢后，你應(yīng)該大概猜到，當表越來越大的時候，性能優(yōu)勢就顯現(xiàn)出來了。

?

兩表關(guān)聯(lián)查詢例子：

在下一個例子中，查詢使用同樣的where子句，但增加了一個inner join 關(guān)聯(lián)另外一個表。第一個查詢的where子句使用col3，并使用col2來關(guān)聯(lián)表。

第二個查詢的where子句使用col2，并使用col3來關(guān)聯(lián)表。

同樣，先執(zhí)行DBCC DROPCLEANBUFFERS來確保緩存已經(jīng)清空。代碼如下：

    DBCC DROPCLEANBUFFERS
  

    GO
  

    SELECT * 
  

    ??FROM dbo.TABLE1 INNER JOIN 
  

    ???????dbo.TABLE2 ON dbo.TABLE1.col2 = dbo.TABLE2.col1
  

     WHERE dbo.TABLE1.col3=255?????? 
  

    GO
  

    DBCC DROPCLEANBUFFERS
  

    GO
  

    SELECT * 
  

    ??FROM dbo.TABLE1 INNER JOIN 
  

    ???????dbo.TABLE2 ON dbo.TABLE1.col3 = dbo.TABLE2.col1
  

     WHERE dbo.TABLE1.col2=255?????? 
  

    GO
  

執(zhí)行計劃如下：

從執(zhí)行計劃可以看到，當用于關(guān)聯(lián)表的列也在索引中，但不是第一列時，會執(zhí)行索引掃描。第二個查詢中索引的第一列來關(guān)列，會使用索引查找。從IO來看，同樣索引查找的讀次數(shù)會更小。

總結(jié)：

從這些例子中，可以看到索引列的順序?qū)Ρ淼牟樵円灿杏绊憽．攧?chuàng)建索引時，先確認你總是對盡可能小的集合進行操作，這意味著索引能從where子句中的列開始。另外，對order by子句中的列和SELECT中的列創(chuàng)建覆蓋索引也有助于提高查詢性能。這樣可以不用在查詢時執(zhí)行書簽查找。

在前面提到的，增加太多索引將引起insert/update/delete時對這些索引列的修改。所以，找到平衡點才是最重要的。

SQL Server 索引列的順序——真的沒關(guān)系嗎