WHERE条件放错位置会导致预索引失效，因优化器被迫全量JOIN后再过滤；应将关联表筛选条件移至ON子句或建立(status,id)复合索引，并用EXPLAIN验证索引使用。
JOIN 时为什么 WHERE 条件放错位置会让预索引失效
MySQL 或 PostgreSQL 中，JOIN 后加 WHERE 筛选，看似合理，但若条件写在主表之外的关联表字段上，优化器可能放弃使用你为关联键建的索引。本质是：数据库得先完成全量 JOIN，再过滤，而不是“边联边筛”。
- 错误写法：
SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active'—— 若users.status没索引，或user_id索引未被覆盖，orders表可能被全扫 - 正确思路：把能提前缩小右表范围的条件挪到
ON子句（仅限LEFT JOIN右表过滤），或确保u.status有复合索引，如(status, id) - 验证方式：用
EXPLAIN看type是否为ref或range，且key列显示用了哪个索引
多维指标聚合时，该用 INNER JOIN 还是 LEFT JOIN
取决于指标定义是否允许“缺失维度”。比如统计“每个城市每类商品的销售额”，若某城市没卖过某类商品，你希望结果里出现 0 还是直接跳过？这直接决定 JOIN 类型和索引策略。
-
INNER JOIN：只保留所有关联表都有匹配的记录；适合“必须存在”的强约束维度（如订单必须有用户、用户必须有地区）；索引只需在各表关联键上独立建好即可 -
LEFT JOIN：主表记录全保留，右表无匹配则补NULL；若后续用COUNT(*)统计，会把NULL行也计入，导致指标虚高；此时应在ON中收紧右表条件，或用COUNT(右表.id)避免误算 - 性能提示：
LEFT JOIN+ 多层嵌套易触发临时表和文件排序，EXPLAIN中看到Using temporary; Using filesort就得警惕
复合索引怎么建才真正加速 JOIN 关联+GROUP BY
单列索引对 JOIN 和 GROUP BY 的联合场景往往不够。数据库需要同时定位关联行、又按分组字段排序/去重，这时索引字段顺序和覆盖程度就关键了。
- 典型陷阱：只为
orders.user_id和orders.status各建一个单列索引，但查询中既JOIN users又GROUP BY u.city, o.product_type，优化器大概率只选其一 - 推荐组合：
CREATE INDEX idx_orders_user_status_type ON orders (user_id, status, product_type)—— 把JOIN键放最左，后续字段按GROUP BY顺序跟上 - 注意点：若
SELECT还要返回orders.amount，最好加上它形成覆盖索引，避免回表；但字段越多，索引体积越大，写入开销上升
预索引关联键后仍慢？检查统计信息和数据倾斜
建了索引、写了 ON 条件、也看了 EXPLAIN 显示走了索引，但查询还是秒级以上——这时候问题常不在 SQL 写法，而在数据分布本身。
- 统计信息过期：
ANALYZE TABLE orders（MySQL）或VACUUM ANALYZE orders（PostgreSQL）强制更新行数、值分布，让优化器不误判选择性 - 数据严重倾斜：比如
user_id = 12345对应 50 万订单，而其他用户平均只有 5 条；索引虽存在，但查这个 ID 仍需扫描大量页；此时考虑分区（按user_idHASH）或业务层拆分热点 - 隐式类型转换：
orders.user_id是BIGINT，users.id是VARCHAR，JOIN 时自动转类型会导致索引失效；用SHOW CREATE TABLE对比字段类型，必须一致
预索引不是银弹，它只加速“找得到”的过程；当“找得到”之后还要处理几百万行，或者根本“找偏了”，就得回到数据结构和业务语义里重新看。
