SQL Server - 維護索引的最佳實踐是什麼？

我正在閱讀索引以優化數據庫性能，並希望針對應用索引的各種數據庫情況收集最佳實踐。SQL Server - 維護索引的最佳實踐是什麼？

對於非平凡數量的表和行，採用完全非索引的數據庫，在確定將什麼類型的列應用於哪種類型以實現最佳性能時，您使用了哪些規則？哪些查詢分析技巧可以使用？

作爲開始我得到：（來自http://asptutorials.net/SQL-Server/tutorial-on-indexes/）

對於主要的或「報頭」的表如發票的表，使表的主鍵上的聚簇索引。
對於輔助或「詳細信息」表（如「invoice_row」），在將子記錄組合在一起的外鍵上生成聚集索引（在本例中爲「invoice_id」）。這是因爲invoice_row表中的大多數查詢將按照invoice_id順序而不是invoice_row_id順序進行。
對於所有表，請在表的每個外鍵上創建一個非聚集索引。此時不要擔心覆蓋索引。考慮您將在桌上執行的選擇查詢。你將使用什麼樣的「where」和「order by」語句？在這些列上創建一個非聚集索引。
現在是時候開始對典型查詢進行計時並查找所有慢速查詢。如果您識別出特別慢的一個，請查看是否有方法可以將額外的非鍵列添加到索引，以便它成爲該查詢的覆蓋索引。

我們可以收集哪些其他「經驗法則」？使用哪些工具？

2009-09-03 Niels Bosma

我不認爲這是一個重複的，至少不是http://stackoverflow.com/questions/107132/what-columns-generally-make-good-indexes的。 – 2009-09-03 21:25:33

我嘗試創建我需要的索引，並在測試或生產環境中使用以下腳本來進一步調整索引。我也有其他一些程序，但是這個程序有一個好的開始。請記住，您必須自己選擇列的最佳順序。

此問題與this question類似，我已經發布了一些其他用於調整索引的存儲過程。

CREATE PROCEDURE [ADMIN].[spMissingIndexes] 
AS 
SELECT 
     mid.statement, 
     mid.equality_columns, 
     mid.inequality_columns, 
     mid.included_columns, 
     migs.user_seeks, 
     migs.user_scans, 
     migs.last_user_seek, 
     migs.avg_user_impact, 
     user_scans, 
     avg_total_user_cost, 
     avg_total_user_cost * avg_user_impact * (user_seeks + user_scans) AS [weight] 
FROM 
     sys.dm_db_missing_index_group_stats AS migs 
     INNER JOIN sys.dm_db_missing_index_groups AS mig 
     ON (migs.group_handle = mig.index_group_handle) 
     INNER JOIN sys.dm_db_missing_index_details AS mid 
     ON (mig.index_handle = mid.index_handle) 
ORDER BY 
     avg_total_user_cost * avg_user_impact * (user_seeks + user_scans) DESC ; 
GO

來源

2009-09-04 20:23:19

一旦定義了主鍵和外鍵索引，就需要分析數據庫的事務活動，以確定適當的索引策略。

SQL Server實際上暗示你可能希望通過多種方式將其納入你的數據庫索引：

缺少的指標Dynamic Management Views。通過查看您的平臺上生成的執行計劃，可以從索引的存在中受益，從而建議可能從數據庫中缺失的索引。
The Database Engine Tuning Advisor。創建SQL Server跟蹤以創建工作負載文件，然後通過DTA運行它以生成建議。

我建議您執行測試以模擬您期望的事務性工作負載，以準確設計和調整您的數據庫。

來源

2009-09-04 08:14:02

數量1 - 分析你的SQL。

你需要看看SQL的數據庫被拋出去尋找哪些指標可能可能是有用的。通過查看計劃分析器，你無法弄清楚需要什麼。

Number 2 - 表空間掃描通常是好東西！如果表格「很小」，或者您正在訪問30％或更多的行，那麼掃描通常是最有效的訪問路徑。

3號 - 索引「小」表是毫無意義的。

數字4 - 索引也可用於檢索。通常將索引的值回溯到索引的後面 - 通常數據庫只會從索引中選擇值，而不會打擾實際的行。例如如果一個普通的SQL是「select max（item_no）where invoice =？」如果您使用發票和item_no建立索引，則可以在不訪問實際表的情況下滿足該查詢。

「小」的當前值約爲2000行。

一定要記住，對於您構建的每個索引，INSERT都存在嚴重的性能損失。

來源

2009-09-04 08:29:18

SQL Server - 維護索引的最佳實踐是什麼？

回答

相關問題