复合索引（id, status）对on a.user_id = b.id and b.status = 'paid'有效，因b+树先用id等值定位子树再过滤status；而（status, id）无效，因status筛选后id无序，无法直接匹配a.user_id，导致范围扫描或全表扫描。
复合索引能加速 JOIN，但必须让 ON 字段和 WHERE 条件共同“挤进”索引的最左前缀，否则基本白建。
为什么 (id, status) 索引对 ON a.user_id = b.id AND b.status = 'paid' 有效，而 (status, id) 无效？
数据库查被驱动表（比如 b 表）时，是拿 a 表的一行值去“定位”匹配行。它依赖 B+ 树从左到右逐级下探：id 是等值查找的起点，status 是在 id 相同的子树里再过滤——这才能跳过全表扫描。
反过来，如果索引是 (status, id)，数据库先按 status 找到一批记录，但这些记录的 id 是乱序的，无法用单次索引查找命中 a.user_id 的具体值，只能扫出所有 status = 'paid' 的行再逐个比对 id，等价于 range + 全表扫描。
-
EXPLAIN里看type：理想是ref或eq_ref；若变成range或ALL，说明索引没真正用上 - 别只盯
key列显示了索引名——那是“选了”，不等于“用了” - MySQL 8.0+ 的 skip scan 在极少数场景可缓解，但别指望它救场
JOIN 字段和 WHERE 条件字段在复合索引里怎么排顺序？
顺序不是按 SQL 里写的先后，而是按字段的“操作类型”和“选择性”：
- 最左必须是高选择性的等值条件字段（如
WHERE u.status = 'active'），它决定索引能切掉多少数据 - 中间放 JOIN 字段（如
u.id），它得能被驱动表的值直接等值定位 - 最后放范围条件（如
u.ctime > '2024-01-01'），它只在前两级筛选后的子树里做范围扫描 - 错误示例：
INDEX (ctime, id)→ctime是范围，id后续失效；正确应为INDEX (status, id, ctime)
哪些操作会让复合索引在 JOIN 中彻底掉线？
哪怕只加一个函数或类型转换，索引就归零：
-
ON DATE(t1.create_time) = DATE(t2.date)→ 两个字段都失去索引能力 -
ON t1.user_id = t2.uid，但t1.user_id是INT、t2.uid是BIGINT→ 类型不一致触发隐式转换，索引放弃 -
ON UPPER(u.name) = UPPER(o.name)→ 函数作用于索引列，无法走索引 - 外键字段没手动建索引 →
ALTER TABLE ... ADD FOREIGN KEY不会自动创建索引，必须单独CREATE INDEX
如何验证复合索引是否真起作用？
只跑 EXPLAIN 不够，重点盯三处：
-
type是ref或eq_ref（不是range、index或ALL） -
rows值接近实际匹配行数（如果远大于，可能是统计信息过期，需ANALYZE TABLE） -
Extra里没有Using temporary或Using filesort（说明排序/分组没走索引路径） - 注意：LEFT JOIN 下把右表条件写进
WHERE（如WHERE u.deleted = 0）会逻辑转成 INNER JOIN，此时索引可能“生效”，但语义已错
最易被忽略的是驱动表本身的选择性——如果驱动表返回 10 万行，就算被驱动表索引再好，也要执行 10 万次索引查找。优化要从“先筛再连”开始，而不是只盯着 JOIN 字段建索引。
