inner join中where与on等效，left join中on控制连接条件、where过滤结果；右表筛选须放on，否则left join退化为inner join；索引需匹配字段类型、选择性高且复合顺序合理。
WHERE 条件写在 JOIN 里还是 ON 里？
对 INNER JOIN 来说，WHERE 和 ON 效果一样，但对 LEFT JOIN 完全不是一回事。把本该过滤左表的条件错放 ON 右侧，会意外变成“过滤后连接”，结果少数据；反过来，把右表过滤条件放 WHERE，会让 LEFT JOIN 退化成 INNER JOIN。
-
ON只控制“怎么连”，不筛最终结果行；WHERE是连接完再筛整行 - 想保留左表全部记录？右表的筛选条件必须写在
ON里（比如ON t2.id = t1.t2_id AND t2.status = 'active'） - 用
EXPLAIN看type字段：如果从ALL变成ref或range，说明条件生效了索引
JOIN 顺序真的影响性能吗？
mysql 5.7+ 会自动重排 JOIN 顺序，但前提是所有表都有可用索引且统计信息准确。一旦某张表没索引、或用了 STRAIGHT_JOIN、或关联字段类型不一致（比如 int 对 VARCHAR），优化器就可能选错驱动表，导致全表扫描。
- 小表驱动大表仍是有效经验——让扫描行数最少的表当驱动表
- 检查
EXPLAIN的rows列：越靠前的表，rows值应该越小 - 字段类型要严格一致：
user_id INT关联order.user_id VARCHAR会导致索引失效 - 临时表（子查询结果）默认无索引，尽量用
WITH替代嵌套子查询，方便优化器估算
哪些字段加索引才真正有用？
不是所有 JOIN 字段或 WHERE 字段都值得建索引。复合索引顺序、选择性、是否覆盖查询，直接决定它能不能被用上。
-
ON和WHERE中出现的字段优先考虑，但单列索引不如按查询顺序建复合索引（如WHERE a = ? AND b = ? ORDER BY c→ 索引(a, b, c)） - 低选择性字段（如
status只有 ‘pending’/’done’ 两种值）单独建索引意义不大，除非配合其他高选择性字段 - 避免冗余索引：
(a, b)存在时，再建(a)就是浪费 - 用
SHOW INDEX FROM table_name看Cardinality，接近总行数才说明选择性好
用 union ALL 代替 OR 联合多个条件？
当 WHERE 里有多个 OR 连接的等值条件（比如 type = 'A' OR type = 'B'），且 type 有索引，MySQL 有时无法有效使用索引。这时候拆成 UNION ALL 可能更快，但要注意去重逻辑和 NULL 处理。
-
UNION ALL不去重、不排序，比UNION快得多；如果业务允许重复，别用UNION - 每个子查询必须结构一致，字段数、类型、顺序都要对得上
- 如果
OR涉及不同字段（如a = 1 OR b = 2），UNION ALL通常没用，改用函数索引或重写逻辑 - 测试时别只看执行时间，用
EXPLAIN format=json看used_columns和key_length，确认索引真被用了
实际调优时最常被忽略的是统计信息过期和字符集隐式转换——ANALYZE TABLE 不是摆设，而 utf8mb4_general_ci 和 utf8mb4_0900_as_cs 混用会导致 JOIN 直接放弃索引。