是否有任何理由不採納數據庫引擎優化顧問的建議？

我在一個團隊維護與SQL Server 2005後端的.Net Web應用程序。最近系統運行速度有點慢，所以在完成所有我們可以想到的調整類型的東西之後（添加索引，清理寫入非常糟糕的存儲過程等），我通過Tuning Advisor運行了一個典型的工作負載，並且它吐出了一個額外的索引和統計數據創建的巨大列表。我最初的反應是說「當然，你知道了，SQL Server」，但是有沒有任何理由不去做顧問說的？是否有任何理由不採納數據庫引擎優化顧問的建議？

來源

2008-09-26 Electrons_Ahoy

如果您啓用了統計信息的自動創建和自動更新（您應該），Sql Server可以很好地管理統計信息，因此請忽略統計信息建議。獲取索引並分析它們以確保您可以處理額外的空間要求，並確保它們不會重複具有相似列的其他索引。您通常可以通過添加一列或兩列（注意列的順序）或添加包含列（覆蓋索引）來合併索引。

如果索引位於使用大量OLAP的表上，則您希望將索引限制爲5-10。對於很少獲得插入或更新的表（每秒少於幾個），空間限制應該是唯一的問題。

調整嚮導建議可以是一個很好的學習工具。採取索引，回到查詢計劃，並試圖找出爲什麼完全是建議。

來源

2008-09-26 17:58:25

像所有的建議一樣，用一粒鹽，並用它來達到你自己的結論。

來源

2008-09-26 17:43:49

索引有2個問題。

索引佔用空間。空間便宜，所以這通常不是針對索引的有力論據。但是，這是值得考慮的。
索引會減慢某些查詢（如插入，更新和刪除）。

創建合適的索引是一種平衡行爲。如果你的系統不夠用，你的系統會很慢。如果你有太多，你的系統會很慢。對於執行更多讀取操作而不是寫入操作的系統，您可以放棄添加更多索引。

來源

2008-09-26 17:48:54

我認爲這個建議很有幫助，但在我看來它只給你一些東西去嘗試。你必須實際做一些基準測試，看看有什麼幫助，哪些沒有。這可能非常耗時，但可能是G Mastros指出的原因。

數據庫優化不是一個直截了當的科學，而是一個爲你確切的情況找到適當平衡的問題。

來源

2008-09-26 17:58:25

請注意DROP INDEX的建議 - 如果您的跟蹤捕獲錯過了一些計劃或罕見的查詢，那麼他們下次運行時可能會受到影響。

來源

2008-09-26 20:14:57 Meff

我推薦這個SQL腳本;它使用內置的性能比較櫃檯建議索引SQL 2005的：

SELECT 
    migs.avg_total_user_cost * (migs.avg_user_impact/100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure, 
    'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle) 
    + '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']' 
    + ' ON ' + mid.statement 
    + ' (' + ISNULL (mid.equality_columns,'') 
    + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END 
    + ISNULL (mid.inequality_columns, '') 
    + ')' 
    + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
    migs.*, mid.database_id, mid.[object_id] 
FROM sys.dm_db_missing_index_groups mig 
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle 
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle 
WHERE migs.avg_total_user_cost * (migs.avg_user_impact/100.0) * (migs.user_seeks + migs.user_scans) > 10 
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

來源

2008-09-27 01:03:01

還要注意的是數據庫的調整將在很大程度上取決於你的使用模式，這可能會改變原型設計，開發和生產之間的很多。所以我最好的建議是現在調整你的心，當你有時間，並瞭解你的改變可能會有什麼影響。它一定會在晚些時候爲您服務。

來源

2008-09-27 01:24:43