有關確定需要創建哪些索引的任何建議？

我處於一種情況，我必須提高用於報告的大約75個存儲過程（由其他人創建）的性能。我的解決方案的第一部分是創建大約6個非規範化表格，這些表格將用於大部分報告。現在我已經創建了表格，我有一些艱鉅的任務來確定我應該創建哪些索引以最好地改善這些存儲過程的性能。有關確定需要創建哪些索引的任何建議？

我很好奇，看看有沒有人有任何建議找到哪些列將有意義包括在索引中？我已經考慮使用Profiler/DTA，或者可能會像下面這樣查詢某種查詢來找出流行的列。

SELECT name, Count(so.name) as hits, so.xtype 
from syscomments as sc 
INNER JOIN sysobjects so ON sc.id=so.id 
WHERE sc.text like '%ColumnNamme%' 
AND xtype = 'P' 
Group by name,so.xtype 
ORDER BY hits desc

讓我知道如果你有任何想法，可以幫助我不必手工挖掘這75個過程。

此外，插入僅在這個DB上每天執行一次，所以插入性能對我來說不是一個大問題。

來源

2010-01-13 Abe Miessler

您可以使用SSMS中的SQL Server分析器查看您的表是如何調用的，然後使用分析器中的數據庫調整工具至少啓動您的正確路徑。我知道大多數DBA可能會尖叫我，因爲我推薦這個，但對於我們這樣的非DBA類型，比如我自己，它至少給了我們一個起點。

來源

2010-01-13 21:13:29 bechbd

是的，這是我正在考慮的選項之一。我聽到很多人都說你不應該依靠這種方法來生成你的索引。 – 2010-01-13 21:20:36

我已經做了相當多的調整，這是我用過的一個很成功的方法。從探查器中，您可以獲得各種有用的信息，尤其是CPU和磁盤IO使用情況。這將告訴你哪些SP最慢（或者至少可以從調優中獲益最多）。然後，您可以打開這些查詢並查看查詢計劃 - 雖然有人真的瞭解Sql查詢計劃嗎？ – MrTelly 2010-01-13 21:41:29

聽起來好像大多數人認爲使用profiler/dta來了解我需要的索引是個好主意。在我的生產服務器上運行Profiler幾個小時可以期待什麼樣的問題？ – 2010-01-13 21:58:30

如果您知道所有活動都來自75個存儲過程，那麼我將使用分析器來跟蹤哪些存儲過程花費最長時間並被稱爲最多。一旦你知道哪些是那些，然後看看那些特效，並查看哪些列最常用的Where子句和JOIN ON部分。最有可能的是，這些列是您希望放置非聚集索引的列。如果一組列經常被同時使用，那麼您很可能需要爲該組創建一個非聚集索引。你可以在一個表上有很多非聚集索引（250），但是你可能不想在其上放一些非聚集索引。我認爲你會發現數據正在被搜索並反覆加入到同一列。記住80/20規則。前20％的工作中，您可能會獲得80％的速度提升。將有一個點，你增加的索引速度增加很少，即當你想停止。

來源

2010-01-13 21:44:00

任何有關確定需要創建索引的建議嗎？

是的！請求Sql Server告訴你。

Sql Server會自動保存統計信息，以便使用哪些索引來提高性能。這已經在你的背景中進行了。請參閱此鏈接：
http://msdn.microsoft.com/en-us/library/ms345417.aspx

嘗試運行這樣的查詢（右從MSDN採取）：

SELECT mig.*, statement AS table_name, 
    column_id, column_name, column_usage 
FROM sys.dm_db_missing_index_details AS mid 
CROSS APPLY sys.dm_db_missing_index_columns (mid.index_handle) 
INNER JOIN sys.dm_db_missing_index_groups AS mig ON mig.index_handle = mid.index_handle 
ORDER BY mig.index_group_handle, mig.index_handle, column_id;

當然，做出真實的，準確的利用這些信息，你需要配置文件的實際執行在任何變化之前和之後的關鍵程序的時間。

來源

2010-01-13 21:47:54

我同意bechbd--使用數據庫流量的一個很好的示例（通過在實際工作時間在生產系統上運行服務器跟蹤以獲得最佳快照），並讓數據庫調整顧問分析該採樣。

我同意你 - 不要盲目依靠數據庫優化顧問告訴你做的一切 - 這只是一個建議，但DTA不能把所有的事情都考慮進去。當然 - 通過添加索引可以加快查詢速度 - 但您會同時放慢插入和更新速度。

而且 - 要真正查出是否有幫助，你需要實現它，再次測量和比較 - 這是真正的唯一可靠方法。涉及的變量和未知量太多。

當然，您可以使用DTA來微調單個查詢以實現出色的性能 - 但這可能會忽略這樣一個事實，即該查詢每週只被稱爲一次，或者通過調整這一個查詢並且添加一個索引，你會傷害其他查詢。

指數調整始終是一個平衡，權衡和試錯類的遊戲 - 這不是一個配方和食譜嚴格確定你所需要的確切的科學。

來源

2010-01-13 21:47:57

如果這是嚴格的報告數據庫，並且您需要性能，請考慮轉移到數據倉庫設計。在報告時，即使是非規範化的關係設計，明星或雪花模式也會表現優異。

來源

2010-01-13 21:55:46

有關確定需要創建哪些索引的任何建議？

回答

相關問題