比較的小さなテーブルの追加の並べ替えがなぜこのようなひどいパフォーマンスを引き起こしているのかを理解するのに苦労しています。次のクエリは、ORDER BY ステートメントで u.list_priority を使用せずに素晴らしいパフォーマンスを発揮します。列に索引が付けられます。
SELECT l.*, u.list_desc
FROM iq_99990022.tbl_vpd_campaign_leads l
INNER JOIN intelliqueue_globalcatalog.tbl_vpd_uploaded_lists u ON l.list_id = u.list_id
WHERE u.campaign_id IN (60238,60241)
AND IFNULL(u.list_state, 'ACTIVE') = 'ACTIVE'
AND l.lead_state = 'READY'
AND l.next_dial_time <= now()
AND l.lead_passes < max_passes
ORDER BY u.list_priority, l.lead_passes ASC
LIMIT 100
これが両方のテーブルのキーです...
u : PRIMARY KEY (`list_id`),
KEY `list_priority` (`list_priority`)
l : PRIMARY KEY (`lead_id`),
UNIQUE KEY `campaign_id` (`campaign_id`,`lead_phone`,`dupe_key_override`),
KEY `next_dial_time` (`next_dial_time`),
KEY `ix_state` (`state`),
KEY `lead_state` (`lead_state`,`campaign_id`,`lead_passes`)
これは、ORDER BY の列を含まない EXPLAIN の結果です...
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE l ref next_dial_time,lead_state lead_state 63 const 15131 Using where; Using filesort
1 SIMPLE u eq_ref PRIMARY PRIMARY 4 iq_99990022.l.list_id 1 Using where
と...
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE l ref next_dial_time,lead_state lead_state 63 const 15131 Using where; Using temporary; Using filesort
1 SIMPLE u eq_ref PRIMARY PRIMARY 4 iq_99990022.l.list_id 1 Using where
異なるデータベース間の結合により、インデックスが使用されなくなる可能性はありますか?