關於多欄索引該怎麼定義，思考往往在「索引被用到了」那一刻就停了下來。

但最佳化工具使用某個索引，不是因為它對這段查詢是「正確」的，而只是因為它比全表掃描更有效率。這不代表它是這段查詢的最佳索引。

前一節的例子已經顯示：從執行計畫中辨識錯誤的欄位順序有多困難。述詞資訊往往藏得很深，你必須刻意去找，才能驗證索引是否被最佳地使用。

述詞資訊藏在哪裡#

以 SQL Server Management Studio 為例，它只有在滑鼠游標懸停於索引操作上時，才以工具提示（tool tip）顯示述詞資訊。使用 SCALE_SLOW 索引的執行計畫，會把 ID2 上的條件顯示為篩選述詞（只寫 Predicate，沒有 Seek）。

從 MySQL 或 PostgreSQL 執行計畫取得述詞資訊更加彆扭，詳見附錄 A。

負載才是真正的放大器#

無論述詞資訊在執行計畫中看起來多麼微不足道，它對效能的影響都極大——尤其在系統成長時。要記得：成長的不只是資料量，還有存取頻率。這是擴展性函數的又一個參數。

• SCALE_SLOW（虛線）：25 個查詢同時執行時，回應時間攀升至 32 秒，是無背景負載時（如同你的開發環境）的 30 倍。
• SCALE_FAST（實線）：沒有任何篩選述詞，即使 25 個查詢並行，回應時間仍穩穩低於兩秒。

即使你在開發環境擁有正式資料庫的完整副本，背景負載仍可能讓查詢在正式環境慢上許多。

別指望「更強的正式硬體」#

開發期間出現的可疑回應時間常被輕輕放過，多半是因為我們期待「更強大的正式硬體」會帶來更好的效能。

下一節會說明：一般而言，期待「更大的硬體」帶來更快的回應，並不合理。