下面給出了限制優化時間和事件數的建議：

• 對于單個查詢和小型工作負荷（少于 100 個事件），請指定無限制的優化時間。如果指定不限制優化時間，數據庫引擎優化顧問將給出最佳建議，并且在大多數情況下，優化會在相對較短的時間內完成。
  
  
• 對于大型工作負荷（多于 100 個事件），請考慮以下方案，其優先級以其列出順序為準。首先考慮方案 1 到方案 3，最后考慮方案 (4)。
  
  
  1. 如果用戶在時間上有約束，請限制優化時間。
     
     
  2. 如果優化固定數量的事件就足夠了（例如，前 10,000 個事件可以代表其余工作負荷），請使用 dta 命令行實用工具，并通過 –n 參數指定事件數。
     
     
  3. 如果使用的是 dta 命令行實用工具，并希望進一步限制優化時間，則可以使用 –A 和 –n 參數。例如，如果指定 -A 240 和 –n 1000 ，則數據庫引擎優化顧問會在優化了 1000 個事件或進行了 4 個小時的優化（以先發生的為準）后立即停止優化。
     
     
  4. 優化所花的時間取決于查詢的復雜性（引用表的數量）、選擇的功能集（優化索引視圖所花的時間比優化索引要多）以及數據（用于創建統計信息）大小。大多數情況下，數據庫引擎優化顧問花在優化上的大部分時間都用在調用查詢優化器上。以下是確定合適的數據庫引擎優化顧問優化時間的一個簡單經驗法則：
     
     對于引用一到三個表的簡單查詢，如果只優化索引，則允許每個查詢用時大約 1 秒，如果優化索引和索引視圖，則允許每個查詢用時大約 10 秒。對于引用三個以上表的復雜查詢，如果只優化索引，則允許每個查詢用時大約 10 秒，如果優化索引和索引視圖，則允許每個查詢用時大約 100 秒。
     
     
• 如果數據庫引擎優化顧問指示已處理 100% 的工作負荷，則表示已分析完全部工作負荷，但不一定進行了優化。若要確定是否優化整個工作負荷，請在優化日志的結尾搜索下列消息：
  
  “工作負荷中的所有事件均未優化。請考慮增大時間限制或者指定在輸入 XML 中要考慮的事件數。”
  
  如果優化日志中存在這樣一條消息，則表明數據庫引擎優化顧問無法優化全部工作負荷。若要解決這種問題，請指定更長的優化時間。若要確保優化工作負荷中的所有事件，可以指定無限制的優化時間。如果選擇不指定不限優化時間，數據庫引擎優化顧問將設法在指定的優化時間內優化盡可能多的事件。
  
  

注意 ???Microsoft SQL Server 2000 索引優化向導中的“快”、“中”或“徹底”模式與數據庫引擎優化顧問中的 -A 和 -n 參數之間沒有直接的映射關系。通常，如果在 SQL Server 2000 中以特定模式（“快”、“中”或“徹底”）進行優化需要一定的時間，則在 SQL Server 2005 數據庫引擎優化顧問中，花同樣的時間通常能給出與之相當或更好的建議。建議使用“徹底”模式的用戶使用數據庫引擎優化顧問，并指定不限制優化時間和工作負荷中要優化的事件數。

限制優化時間和事件數的最佳方法