如何在 MySQL 中對可切換優化進行基準測試

我想對MySQL 中可切換優化的性能進行基準測試，即比較查詢延遲和EXPLAIN使用/不使用這些優化開關的結果。

我已經嘗試過使用sysbench和 MySQL 官方test-suite。但我喜歡它們過於籠統，主要用於功能測試，即在有/沒有優化開關的情況下執行這些測試，性能幾乎相同。我想要的是一個性能測試套件。

您能否建議我一些好的工具/套件來滿足我的需求？謝謝！

（我意識到這並沒有“回答”這個問題。但是評論太長了。）

祝你好運。重新“幾乎相同”——可能是因為它們“相同”，除了時間上的隨機雜訊。可切換的優化通常是“二進制”和“可選”。

考慮一個明顯的情況：您有一個可以在查詢中使用的索引。儘管如此，優化器還是會刻意考慮是否忽略索引而簡單地掃描表。在索引和表之間跳轉可能成本更高，因此使用索引會減慢執行速度。這是一個“二元”決定——使用與忽略索引。優化器無法知道選擇之間的確切截止值。它受 HDD 與 SDD、buffer_pool_size、其他活動、統計資訊等的影響。

也就是說，如果有兩個以上的選擇（索引是否存在），基準會變得複雜：

• FORCE INDEXvs IGNORE INDEXvs “允許”優化器選擇
• 對於“允許”，優化器選擇更好的選擇而不是失敗

這些中的任何一個都可能改變優化器是否會選擇特定的優化。此外，在以下情況下，時間會發生相對不可預測的變化：

• 向表中添加更多行
• 更改“範圍”的大小
• ANALYZE TABLE有時會導致事情發生重大變化。
• OPTIMIZE TABLE——同上。

多年來，我偶爾會看到“索引合併相交”。( INDEX(a), INDEX(b)with WHERE a=1 AND b=2) 在任何情況下，複合索引都會更好 ( INDEX(a,b))。

將其更改AND為OR並且沒有索引是有用的——除非使用“索引合併聯合”。這幾乎不會發生。它需要兩次索引範圍掃描，一次合併，然後是“連接”。

EXPLAIN沒有顯示太多資訊。 EXPLAIN FORMAT=JSON更好。優化器跟踪顯示一組不同的資訊。

我不知道像您所尋求的測試集。我認為即使是一個測試的編寫也是一個相當大的挑戰（見上文）。此外，解釋結果將具有挑戰性。

如果您確實成功實現了目標，請在部落格中介紹它。

引用自：https://dba.stackexchange.com/questions/273031