JOIN顺序由优化器基于成本模型决定，非SQL书写顺序；真正执行顺序以EXPLAIN输出的table列为据；LEFT JOIN右表过滤条件须写在ON中，否则退化为INNER JOIN；多表JOIN需确保ON条件完整、字段有索引，避免笛卡尔积。

JOIN顺序由优化器决定，不是你写的顺序

数据库不会按你SQL里FROM A JOIN B JOIN C的书写顺序执行。MySQL、PostgreSQL等会基于统计信息（行数、索引区分度）、成本模型选择代价最低的连接路径——可能先连A和C，再用结果去连B。这意味着调换表位置无法“强制先过滤小表”。

验证实际顺序的方法是看EXPLAIN输出：id最小且type为const、ref或range（非ALL）的那行，通常是驱动表；第一行不等于最先写的表。

• 旧版MySQL（5.7之前）优化器较弱，可临时用STRAIGHT_JOIN强制顺序，但绕过优化器有风险，必须实测
• 不要依赖“把小表写前面”来提速，真正有效的是让小表带高选择性WHERE条件，且索引覆盖JOIN字段
• 三张及以上表JOIN时，漏写任一ON条件极易触发笛卡尔积——比如A(1000)×B(1000)×C(1000) = 10亿行

LEFT JOIN中ON和WHERE对右表的过滤效果完全不同

ON在关联阶段生效，WHERE在关联完成后才过滤。这个区别在LEFT JOIN里直接决定左表是否“全量保留”。

错误写法：LEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active'——NULL值不满足等值判断，所有没匹配到active用户的订单行都会被干掉，LEFT JOIN退化成INNER JOIN。

• 要保留左表全部记录，只取右表满足条件的部分：把条件写进ON，如ON o.user_id = u.id AND u.status = 'active'
• 想先完整关联再筛结果：可用WHERE，但右表字段只能做IS NULL或IS NOT NULL判断，否则仍会丢左表行
• 某些旧版PostgreSQL不支持ON里对右表做非等值条件（如u.status = 'active'），需查对应版本文档

多次引用同一张表必须用不同别名

同一个表在FROM或JOIN中出现多次，别名必须唯一。否则解析失败，报错ERROR 1066 (42000): Not unique table/alias。

例如订单表要关联创建人、审核人、负责人（都来自users表），不能两次都写JOIN users u。

• 正确写法：JOIN users creator ON o.creator_id = creator.id，JOIN users auditor ON o.auditor_id = auditor.id
• 别名建议带语义（如creator、auditor），比u1/u2更易维护
• SELECT中所有同名列必须加前缀，否则报ambiguous column，例如不能写SELECT id，得写SELECT creator.id

驱动表选错是多表JOIN慢的最常见原因

驱动表被当作外层循环，每行都要去探查被驱动表。如果驱动表本身很大（如100万行），又没索引支撑JOIN条件，被驱动表就会被扫描100万次。

典型现象：慢查询日志显示Rows_examined远大于单表行数，比如t1有100行、t2有10万行，但Rows_examined高达上千万。

• 优先选带高选择性WHERE条件的表作驱动表（如WHERE status = 'paid' AND ctime > '2024-01-01'），让它先被过滤缩小
• JOIN字段类型必须严格一致（int vs bigint、varchar(50) vs varchar(100)、是否带COLLATE），否则索引可能失效
• 外键字段不等于自动有索引，务必手动确认并创建；复合索引顺序应为：等值条件字段 → 范围条件字段 → JOIN字段（用于覆盖）

实际执行计划永远比手写顺序重要。哪怕你把所有优化点都做了，如果表统计信息过期（比如大表刚导入百万数据但没ANALYZE TABLE），优化器照样可能选错路径。