我們有一個大表（包含34列數字或日期時間數據的4.5億行），目前大約有一打推薦的查詢路徑。該表目前有17個索引，我無權改變此表的結構，儘管我能夠提供索引策略。SQL SERVER中的極大表應該如何索引？
我看到的第一個問題是沒有聚集索引，說明該表有一個由2列組成的唯一鍵。我想我可以改變它，然後處理其他索引。由於大約有十幾種常用的查詢方法，我認爲爲每個查詢方法添加一個索引是一件好事。所以說，查詢表的一種常見方式是通過CustomerId，我會在客戶ID上添加一個索引。這將是一個非聚集索引，但仍然是相當低效的權利？如果我使索引包含CustomerId和聚集索引中的2列，該怎麼辦？這會使SQL Server在其執行計劃中更有效率，還是這是一項無用的任務？
我認爲，最好的策略是一直陪在你的數據庫上運行的SQL Server事件探查一段時間來啓動。一旦你有一個體面的跟蹤存儲在文件或專用的跟蹤表，然後你可以運行SQL Server數據庫調整顧問來獲得真正的統計和索引建議根據您的數據庫的實際使用，而不是假設你如何看待查找行爲在你的分貝。
實際上，您的表上可能存在某些昂貴的查詢，這些查詢目前完全繞過了您不知道的現有配置索引。該工具將幫助您追蹤最佳組合。
下面是這種在實踐中的例子：
僅當數據根據聚集列順序插入時才更改爲使用聚簇索引。如果您使用的列不是唯一的，那麼數據庫將在表中添加一個4字節的唯一性列，因此請確保它們是唯一的。
一個聚簇索引的範圍查詢（WHERE KeyColumn BETWEEN（...））
在您的客戶編號例子有優勢在添加主列時絕對沒有收穫。非客戶化索引將包含到集羣頁面的項目引用。
其實你的問題沒有包含任何信息來建立一個好的建議。你最好從分析中找出任何瓶頸。
索引用於高效的數據檢索。
您應該查看針對大表運行的查詢並確定哪些列最常用。
這裏有一些經驗規則進行索引：
在倉庫環境中使用的綜合指數，因爲它們很習慣datetime列是較好的選擇聚簇索引經常在WHERE子句中。
那麼你如何看待這一切呢？
運行SQL Server Profiler。這將幫助您查找對您的表運行的查詢。然後通過查看運行次數和查詢成本，找出在給定時間段內使用最多資源的那些資源。按照兩個路徑中的一個更好的索引
+1讓優化顧問決定什麼是真正發生的事情，而不是猜測。關於那個人最好的部分是他願意在一夜之間工作，或者當我在午餐時工作，所以我可以在方便時回來查看他的工作。 – Tom 2010-03-24 13:53:25
@Tom，正好。我曾經幫助建議一個擁有龐大數據庫的客戶，他們運行的報告大約需要45分鐘才能返回。事實證明，用戶查詢數據的方式沒有預料到，主表上的所有現有索引都沒有用。對於主要查詢來說，一段好日子的sql分析可以將其降低到20秒。 – 2010-03-24 14:02:14