如何確認或反駁由於維護的索引過多而導致性能下降
我們知道索引改進
select了語句，同時索引對每個update/insert/delete語句都有維護成本。我不知道如何衡量/評估這個成本。
一些上下文：有十幾個鍵表涉及多個插入/更新，行數在 20M 到 80M 之間。平均每秒 1400 筆交易。
在過去的幾個月裡，添加了幾個索引來優化系統不同部分的性能。這工作正常，但現在系統的另一部分出現了一些退化。
我有這個理論，但我不知道如何驗證或反駁它。
編輯：我讀過其他一些文章，但大多數都是面向 SQL Server 的，我正在執行
SYBASE ASE 15.7，如 tagged
在嘗試確定要禁用（在 Sybase ASE 中不可行）或刪除哪些索引之前，我希望更好地了解“系統另一部分出現某些退化”的含義。我想要更多關於退化類型和程度的詳細資訊。
為了討論起見，我將假設“降級”是指一些現在表現不佳的查詢，在這種情況下，我想看看為（重新）調整所述查詢所做的工作；查詢計劃是否顯示正在使用的“錯誤”索引？查詢計劃是否顯示“錯誤”連接順序？
是的，性能下降可能與索引數量的增加有關，但我認為性能下降與更新索引的成本沒有任何關係（再次假設“降級”是相關的到現在執行不佳的查詢），而是生成“糟糕”的查詢計劃。
在優化查詢時，Sybase ASE 將嘗試評估每個可能的連接順序，利用每個可能的索引，利用所有可能的列和索引的每個可能的統計資訊。最終結果是優化器對於引用大量表、索引和列統計資訊的查詢有很多工作要做。
雖然從技術上講，Sybase ASE 優化器在嘗試優化一些笨拙、粗糙的查詢時可能會關閉一個小時……是的，優化器確實有一些“智能”，可以快速消除一些連接/索引組合……實際上，優化器對搜尋“最佳”查詢計劃的時間有限制（通過配置參數），（不幸的）結果是，對於非常大、複雜的查詢，優化器可能會在之前超時它找到了“最佳”查詢計劃，從而為我們留下了“目前為止最好的”（即效率不高）查詢計劃。
假設您的降級問題與一些突然開始表現不佳的查詢有關，我猜測額外的索引可能會增加優化器的工作量，以至於它現在在找到“最佳”之前超時’查詢計劃。
在這種情況下，有一些（重新）調整查詢的選項……給優化器更多的時間來找到“最好的”（或至少一個“更好的”）查詢計劃……提供提示（例如，索引提示，抽象查詢計劃）以限制優化器必須考慮的組合…重寫查詢以簡化優化器的工作量…
雖然您看到的退化可能還有其他一些解釋，但第一步是獲取有關退化類型和程度的更多詳細資訊……我們在這個執行緒中沒有給出……並且（不幸的是）一個可能太大/太複雜而無法在此媒體中詳細介紹的過程。