2

3つのテーブルを結合し、1つのテーブルをそれ自体に自己結合する複雑なMySQLクエリがあります。

同一のデータとインデックスを持つマスターとスレーブがあります。マスターはスレーブと比較して強力なボックスですが、クエリはスレーブで10倍高速に実行されます（マスターの負荷が軽い期間中）。

実行計画は大きく異なります。

Master execution plan
1, 'SIMPLE', 'table3_', 'const', 'PRIMARY', 'PRIMARY', '12', 'const', 1, 100.00, 'Using temporary; Using filesort'
1, 'SIMPLE', 'table2_', 'ref', 'PRIMARY,FK376E02E910238FCA', 'FK376E02E910238FCA', '13', 'const', 105, 100.00, 'Using where'
1, 'SIMPLE', 'table0_', 'ref', 'FK57012F937DD0DC02,FK57012F9398CD28D0', 'FK57012F9398CD28D0', '13', 'table2_.ID', 1515, 100.00, 'Using where'
1, 'SIMPLE', 'table1_', 'eq_ref', 'PRIMARY,FKE7E81F1ED170D4C9', 'PRIMARY', '8', 'table0_.FK_ID', 1, 100.00, 'Using where'

Slave execution plan
1, 'SIMPLE', 'table3_', 'const', 'PRIMARY', 'PRIMARY', '12', 'const', 1, 100.00, 'Using filesort'
1, 'SIMPLE', 'table1_', 'ref', 'PRIMARY,FKE7E81F1ED170D4C9', 'FKE7E81F1ED170D4C9', '9', 'const', 187398, 100.00, 'Using where'
1, 'SIMPLE', 'table0_', 'ref', 'FK57012F937DD0DC02,FK57012F9398CD28D0', 'FK57012F937DD0DC02', '9', 'table1_.ID', 1, 100.00, 'Using where'
1, 'SIMPLE', 'table2_', 'eq_ref', 'PRIMARY,FK376E02E910238FCA', 'PRIMARY', '12', 'table0_.FK_ID', 1, 100.00, 'Using where'

テーブルはさまざまな順序で処理され、マスターDBは一時テーブルとファイルソートの両方を使用しますが、スレーブはファイルソートのみを使用します。

実行時間が大幅に異なるさまざまな計画を引き起こす可能性のある要因は何ですか？

アップデート：

これがインデックス統計に関係している可能性はありますか？少量の期間にマスターでANALYZETABLEを実行する予定です。SHOW INDEXは、マスターとスレーブの間でいくつかのキーのカーディナリティが大きく異なることを示しています。

4

3 に答える 3

2

MySQLは、収集された統計に基づいてクエリを最適化します。

出力を見ると、異なるキーを使用していることがわかります。キーのヒントを追加したり、キーを強制したりする必要がある場合があります

FROM table2_ JOIN

になる必要があります

FROM table2_ USE KEY（'FK376E02E910238FCA'）JOIN

またはFORCEKEY

于 2009-12-15T19:44:39.730 に答える
0

これは、私にはクエリオプティマイザのバグのように見えます。私はそれを報告します。

両方のサーバーが同じバージョンのMySQL上にありますか？

于 2009-12-15T19:16:25.030 に答える
0

SHOW INDEXは、マスターとスレーブの間でいくつかのキーのカーディナリティが大きく異なることを示しています。

同じ問題に遭遇しましたが、その理由は、カーディナリティの違いであることがわかりました。次に、分析テーブルを実行しました。カーディナリティは同じで、問題は解決しました。

于 2021-01-20T05:58:14.093 に答える