は、私はこのクエリに問題がある

Question

同じクラスタに計画を説明します。ノード0-3と4の違いは、最初のものがバランサにあり、ノード4がバランサから外れている（しかしクラスタ内にある）ことです。

問題は4つのサーバー-3）クエリーが本当に遅い（15秒）、もう1つ（ノード4）クエリーが本当に速い（0,002）

アフリカ、説明計画は同じでなければならないが、私はEXPLAINと結果を実行する（スロー）

 
+----+-------------+-------+------+-------------------------------------------------------------+--------------+---------+-------------------------------+---------+---------------------------------------+ 
| id | select_type | table | type | possible_keys            | key   | key_len | ref       | rows | Extra         | 
+----+-------------+-------+------+-------------------------------------------------------------+--------------+---------+-------------------------------+---------+---------------------------------------+ 
| 1 | SIMPLE  | uca2 | ref | PRIMARY,user_call_id,user_call_id_2       | user_call_id | 4  | const       |  1 | Using index       | 
| 1 | SIMPLE  | uc | ALL | PRIMARY,user_call_id          | NULL   | NULL | NULL       | 2098152 | Using join buffer (Block Nested Loop) | 
| 1 | SIMPLE  | uca | ref | user_call_id,user_call_id_2,is_validated_with    | user_call_id | 4  | db.uc.user_call_id   |  1 | Using where       | 
+----+-------------+-------+------+-------------------------------------------------------------+--------------+---------+-------------------------------+---------+---------------------------------------+ 

ノード0-3：これは、 10ノード4（高速）

 
+----+-------------+-------+--------+-------------------------------------------------------------+---------------------------------+---------+-----------------------------------+---------+-----------------------+ 
| id | select_type | table | type | possible_keys            | key        | key_len | ref        | rows | Extra     | 
+----+-------------+-------+--------+-------------------------------------------------------------+---------------------------------+---------+-----------------------------------+---------+-----------------------+ 
| 1 | SIMPLE  | uca2 | ref | PRIMARY,user_call_id,user_call_id_2       | user_call_id     | 4  | const        |  1 | Using index   | 
| 1 | SIMPLE  | uca | ref | user_call_id,user_call_id_2,is_validated_with    | is_validated_with    | 5  | db.uc2.user_activity_id   | 2755595 | Using index condition | 
| 1 | SIMPLE  | uc | eq_ref | PRIMARY,user_call_id          | PRIMARY       | 4  | db.uca.user_call_id    |  1 | NULL     | 
+----+-------------+-------+--------+-------------------------------------------------------------+---------------------------------+---------+-----------------------------------+---------+-----------------------+ 

私は、低速のものではインデックスが使用されていないことに気付きます。

ノード0：

 
+-----------------+------------+----------------------+--------------+----------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| Table   | Non_unique | Key_name    | Seq_in_index | Column_name   | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | 
+-----------------+------------+----------------------+--------------+----------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| users_calls  |   0 | PRIMARY    |   1 | user_call_id   | A   |  2099153 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | call_group_id  |   1 | call_group_id  | A   |  16659 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | user_call_begin_date |   1 | user_call_begin_date | A   |  1049576 |  NULL | NULL | YES | BTREE  |   |    | 
| users_calls  |   1 | user_call_begin_date |   2 | user_call_end_date | A   |  2099153 |  NULL | NULL | YES | BTREE  |   |    | 
| users_calls  |   1 | user_call_id   |   1 | user_call_id   | A   |  2099153 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | user_call_id   |   2 | user_id    | A   |  2099153 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | user_id    |   1 | user_id    | A   |  91267 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | user_id    |   2 | call_id    | A   |  2099153 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | user_id    |   3 | user_call_status  | A   |  2099153 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | fk_users_calls_calls |   1 | call_id    | A   |  23067 |  NULL | NULL |  | BTREE  |   |    | 
+-----------------+------------+----------------------+--------------+----------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 

ノード4：インデックスが異なっている理由

 
+-----------------+------------+----------------------+--------------+----------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| Table   | Non_unique | Key_name    | Seq_in_index | Column_name   | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | 
+-----------------+------------+----------------------+--------------+----------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 
| users_calls  |   0 | PRIMARY    |   1 | user_call_id   | A   |  2091476 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | call_group_id  |   1 | call_group_id  | A   |  26813 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | user_call_begin_date |   1 | user_call_begin_date | A   |  1045738 |  NULL | NULL | YES | BTREE  |   |    | 
| users_calls  |   1 | user_call_begin_date |   2 | user_call_end_date | A   |  2091476 |  NULL | NULL | YES | BTREE  |   |    | 
| users_calls  |   1 | user_call_id   |   1 | user_call_id   | A   |  2091476 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | user_call_id   |   2 | user_id    | A   |  2091476 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | user_id    |   1 | user_id    | A   |  53627 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | user_id    |   2 | call_id    | A   |  2091476 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | user_id    |   3 | user_call_status  | A   |  2091476 |  NULL | NULL |  | BTREE  |   |    | 
| users_calls  |   1 | fk_users_calls_calls |   1 | call_id    | A   |  15608 |  NULL | NULL |  | BTREE  |   |    | 
+-----------------+------------+----------------------+--------------+----------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 

私の最初の質問ですので、私は、インデックスをチェックしますか？両方が同じクラスタの権利のために同じである必要がありますか？

なぜ実行計画が異なるのですか？両方とも同じクラスタにあるので、同じにする必要があります

FORCE INDEXまたはSTRAIGHT_JOINを使用しますか？

Answer 1

両方のテーブルにuser_call_idフィールドがあると思います。あなたはこのようなあなたのクエリを変更した場合には、インデックスを使用するようにサーバーを強制します：

SELECT 
    uca.user_activity_id, 
    uca.user_call_id, 
    uca.call_activity_id, 
    uca.user_activity_token, 
    uc.call_group_id, 
    uc.user_id 
FROM users_calls_activities uca 
INNER JOIN users_calls_activities uca2 ON uca2.user_activity_id = uca.user_activity_is_validated_with AND uca2.user_call_id = 1744136 
INNER JOIN users_calls uc ON uc.user_call_id = uca.user_call_id uc.user_call_id = 1744136 
WHERE uca.user_call_id = 1744136; 

Answer 2

を答えは二つに隠されている出力を説明 - ノード4に、第二の参加ucaテーブルの上にインデックスis_validated_withを使用していますが、予想される行数は2755595であり、これは他の計画のuc表のフルスキャンの行数よりも大きくなります。

利用可能な情報では確かに言い難いですが、ノード0-3はnode4が使用されていない間にアクティブな使用が見られるため、オプティマイザがクエリプランを決定するために使用する統計情報は反映されなくなる可能性がありますテーブルの実際の状態すべてのノードの3つのテーブルすべてでANALYZE TABLEを実行しようとすると、同じプランが生成されていることがわかります（すべてのノードが同じデータを持っていると仮定します）。

FORCE_INDEXを使用するほかに、optimizer flagsを調整して1つのプランを優先させることもできますが、基本的な問題を修正する方が一般的には優れています。後で。