JOIN优化核心是驱动表筛选性与复合索引匹配：WHERE字段需纳入ON关联字段的复合索引最左列，驱动表rows应小，避免函数导致索引失效，COUNT(*)优于COUNT(可空字段)。
WHERE 条件里用的字段，必须出现在 JOIN 的 ON 子句对应索引最左列
数据库优化器在执行 JOIN 时，通常只对 ON 子句中涉及的字段做索引下推。如果 WHERE 过滤字段没被包含进关联字段的复合索引里，即使单列有索引，也可能退化成全表扫描。
常见错误现象：EXPLAIN 显示 type=ALL 或 key=NULL，哪怕 WHERE 条件看起来很“精准”。
- 例如：两个表按
user_id关联，但查询还加了AND status = 'active'→ 复合索引得是(user_id, status)，而不是只建user_id单列索引 - MySQL 8.0+ 支持索引跳跃扫描（skip scan），但仅限于前导列值重复率极低的场景，别默认依赖它
- PostgreSQL 对
JOIN ... ON a.x = b.y WHERE b.z = ?的索引选择更激进，但依然要求b.y和b.z同属一个复合索引，否则可能放弃使用索引
多表 JOIN 时，驱动表的筛选性决定索引是否生效
驱动表（即 EXPLAIN 中 id 最小、且没被物化或延迟关联的那张表）的过滤强度，直接影响后续表能否命中索引。驱动表返回 10 行和返回 10 万行，对被驱动表的索引访问次数差两个数量级。
使用场景：分析订单、用户、商品三表关联时，若先筛出「近 7 天下单用户」再连订单明细，比先连所有用户再 WHERE order_time > ... 更容易走索引。
- 检查
rows列：驱动表的rows值应尽量小；如果远大于实际匹配数，说明统计信息过期，需ANALYZE TABLE - 避免在驱动表
ON字段上用函数：如ON DATE(created_at) = '2024-01-01'会让索引失效，改用范围查询created_at >= '2024-01-01' AND created_at - SQL Server 的嵌套循环（Nested Loop）对驱动表筛选性极度敏感；TiDB 在 MPP 模式下会自动重排驱动顺序，但前提是各表都有准确的统计信息
复合索引字段顺序不是按 JOIN 出现顺序，而是按「等值 → 范围 → 排序」排列
很多人误以为 JOIN ... ON a.x = b.x AND a.y = b.y 就该建 (x, y) 索引，其实还要看后续有没有 WHERE 或 ORDER BY。真正决定顺序的是字段在查询中的“操作类型”。
参数差异：MySQL 的索引最左前缀原则不等于“最左等值”，它允许跳过中间的等值条件，但不能跳过范围条件之后的字段。
- 典型错误：为
WHERE user_id = ? AND status IN ('a','b') ORDER BY created_at DESC建(user_id, created_at, status)→status是IN（范围），created_at在它后面就无法用于排序，应改为(user_id, status, created_at) - PostgreSQL 的 B-tree 索引支持混合等值+范围+排序，但只有等值字段在前时，后面的范围/排序才能生效；
(a, b, c)可用于WHERE a = ? AND b > ? ORDER BY c，但不能用于WHERE a > ? ORDER BY b, c - 注意 NULL 处理：如果字段允许 NULL，
IS NULL在 MySQL 中可能无法走索引（尤其在复合索引中间位置），建议用COALESCE(col, '')配合函数索引（MySQL 8.0+）或业务层规避
JOIN 后 COUNT(*) 和 COUNT(非空字段) 的索引利用差异极大
COUNT(*) 只要能定位到满足 JOIN 条件的行即可，引擎常选最小可用索引；而 COUNT(col) 若 col 允许 NULL，就必须回表或读取完整字段值判断是否为空，导致索引失效风险陡增。
性能影响：在千万级关联结果集上，COUNT(id)（id 是主键）和 COUNT(status)（status 是普通可空字段）执行时间可能相差 5–10 倍。
- 优先用
COUNT(*)：现代优化器已足够聪明，它知道主键非空，不会傻乎乎去读整行 - 如果必须统计某字段非空数，且该字段高频查询，考虑加函数索引：
CREATE INDEX idx_status_notnull ON t ((status IS NOT NULL))（PostgreSQL）或CREATE INDEX idx_status_nn ON t (status) WHERE status IS NOT NULL（SQL Server） - MySQL 不支持部分索引，此时可冗余一个标记字段
status_notnull TINYINT，配合触发器维护，用COUNT(status_notnull)替代
多维 JOIN 的索引不是堆砌字段，而是把查询逻辑拆解成「驱动路径 + 关联约束 + 过滤条件 + 聚合需求」四层，每一层都可能卡住索引生效。最容易被忽略的是：你以为在优化 JOIN，其实瓶颈早就在第一张表的 WHERE 扫描里了。
