联合索引不能简单按JOIN字段堆砌，因为MySQL依赖最左前缀匹配，而驱动表与被驱动表角色、JOIN执行顺序及过滤条件位置共同决定索引是否生效；若索引字段顺序不匹配被驱动表的等值→范围→排序需求，或混入范围条件后字段无法参与匹配，将导致全索引扫描甚至退化为全表扫描。
为什么联合索引不能简单按JOIN字段堆砌
看到 JOIN 多个字段，第一反应是把所有 ON 条件字段塞进一个联合索引——这大概率会让查询更慢。因为 MySQL 的联合索引生效依赖最左前缀匹配，而 JOIN 条件的执行顺序、驱动表与被驱动表的角色、过滤条件的位置，都会影响索引是否真正被用上。
比如 SELECT * FROM A JOIN B ON A.id = B.a_id AND A.status = B.a_status AND A.category_id = B.category_id，如果只建 (a_id, a_status, category_id)，但实际 B 表是驱动表（即 B 先扫描），那这个索引对 B 完全无效——B 需要的是能快速定位自身行的索引，而不是为 A 准备的。
- 先确认哪张表是驱动表（用
EXPLAIN看table列顺序和type值） - 被驱动表的
ON字段必须有索引，且该索引应以「等值匹配字段」开头 - 如果
ON中混有范围条件（如A.created_at > '2025-01-01'），它之后的字段无法参与最左前缀匹配 - 避免把高基数字段（如
id）放在联合索引末尾——它对过滤帮助小，却拖长索引长度
被驱动表的联合索引该怎么排字段顺序
核心原则：等值字段在前，范围字段居中，排序/分组字段靠后。这不是教科书口诀，而是由 B+ 树结构和查询优化器行为决定的。
例如被驱动表 user_like_post 上有查询：SELECT * FROM post p JOIN user_like_post ulp ON p.id = ulp.postId WHERE ulp.userId = 123 AND ulp.createdAt >= '2026-08-01'，这里 ulp 是被驱动表，userId 是等值，createdAt 是范围。
- 正确索引：
(userId, createdAt)——userId等值过滤后，B+ 树内可直接按createdAt范围扫描叶子节点 - 错误索引：
(createdAt, userId)——createdAt是范围，无法用最左前缀约束userId，导致全索引扫描 - 如果还有
ORDER BY ulp.createdAt DESC，该索引依然有效；但若改成ORDER BY ulp.userId, ulp.createdAt，则需补成(userId, createdAt)，因已满足覆盖排序字段顺序 - 别加冗余字段：如果
SELECT只要postId，而索引里已有userId和createdAt，那就别硬塞postId进去——除非你想避免回表
超宽表 JOIN 时如何避免回表放大 I/O
当被驱动表字段多、单行数据大（比如含 TEXT 或多个 VARCHAR(500)），即使走了索引，回表读聚簇索引页也可能成为瓶颈。这时「覆盖索引」不是可选项，是刚需。
仍以 user_like_post 为例：若查询常要 SELECT postId, createdAt, status，而当前索引只有 (userId, createdAt)，那么每次匹配都要回表取 status，I/O 次数翻倍。
- 把
SELECT中所有非主键字段都加进联合索引末尾，构成覆盖索引，如(userId, createdAt, postId, status) - 注意顺序：等值字段 → 范围字段 → 覆盖字段（不参与过滤/排序的字段放最后）
- 警惕宽度爆炸：如果要覆盖的字段太多（比如超过 5 个，或含长文本），索引体积会急剧上升，写入性能下降，反而得不偿失
- 替代方案：用
INT或BIGINT代理大字段（如用status_id替代status VARCHAR(50)），再关联字典表，平衡空间与 I/O
小表驱动大表时，索引建在哪张表上
很多人卡在这一步：JOIN 写法是 A JOIN B，就默认索引得建在 B 上。错。关键看 EXPLAIN 输出里哪张表的 rows 小、type 是 ref 或 eq_ref——那个才是被驱动表，索引必须落在它身上。
例如：SELECT * FROM comment c JOIN post p ON c.postId = p.id WHERE c.userId = 456。如果 comment 表只有几千行，post 表有千万行，优化器很可能选 comment 当驱动表（rows=200），post 当被驱动表（rows=1）。此时 post.id 必须有主键索引（已有），而 comment 上需要的是 (userId, postId) ——前者过滤，后者支撑 JOIN 查找。
- 永远以
EXPLAIN的Extra列为准：Using index condition表示索引下推生效，Using where; Using index表示覆盖索引，Using join buffer是危险信号（说明没走索引） - 统计信息过期会导致优化器误判驱动表，定期执行
ANALYZE TABLE table_name - 用
STRAIGHT_JOIN强制驱动顺序仅限调试，线上慎用——它绕过优化器，一旦数据分布变化，性能可能断崖下跌
真正难的不是建索引，是判断哪张表在本次查询中实际承担了「被查找」的角色。很多慢 JOIN 的根因，是开发者盯着 SQL 文本想逻辑，却没看优化器到底怎么执行的。
