join执行顺序由优化器决定，非sql书写顺序；left join中on过滤右表可保左表全量，where过滤则退化为inner join；驱动表应选结果集最小、索引高效者，通过explain验证type和rows。
JOIN执行顺序由优化器决定，不是按SQL书写顺序
MySQL、PostgreSQL等主流数据库的JOIN执行顺序不等于你写的表顺序。比如FROM A JOIN B ON ... JOIN C ON ...，优化器可能先连A和C，再用结果去连B——只要代价更低，它就会重排。
这意味着你不能靠调换表位置来“提前过滤大表”。想控制数据量，得靠WHERE条件或子查询提前筛行，而不是寄希望于“先JOIN小表”。
- 用
EXPLAIN看实际驱动表：type为const或ref的通常是驱动表，第一行就是它 - 大表当驱动表容易慢；带高选择性索引的小表更适合作为驱动表
- MySQL 5.7之前优化器较弱，可用
STRAIGHT_JOIN强制顺序，但绕过优化器风险高，需实测验证
ON和WHERE在LEFT JOIN里生效时机完全不同
ON是关联时判断，WHERE是关联后过滤。这个区别在LEFT JOIN中尤其致命。
错误写法：LEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active'——这会让所有没匹配到active用户的订单整行消失，LEFT JOIN实际退化成INNER JOIN。
- 要保留左表全部记录，只取右表满足条件的部分：把条件写进
ON，如ON o.user_id = u.id AND u.status = 'active' - 想先完整关联再筛结果：用
WHERE，但必须避开对右表字段做非IS NULL判断，否则会丢左表行 - 某些旧版PostgreSQL不允许
ON里对右表字段做非等值判断（如u.status = 'active'），得查对应版本文档
多次引用同一张表必须用不同别名
同一个表在FROM或JOIN里出现多次，别名必须唯一。否则解析失败，报错ERROR 1066 (42000): Not unique table/alias。
比如订单表orders要关联创建人、审核人、负责人，都来自users表，就不能两次都用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不是线性两两连接，而是嵌套循环或哈希连接
三张表JOIN，并不是先算A JOIN B得到中间结果，再拿它去JOIN C。现代数据库大多采用嵌套循环连接（Nested Loop Join）或哈希连接（Hash Join），本质是“以驱动表为外层，逐行探查被驱动表”，C表可能被反复扫描。
典型现象：慢查询日志显示Rows_examined远大于单表行数，比如t1有100行、t2有1000行、t3有200行，但总扫描行数达24100——这就是嵌套循环的代价。
- 没索引时，被驱动表每行都要全表扫一遍；有合适索引才能落到
ref或eq_ref级别 -
USING语法虽简洁，但兼容性差（某些版本不支持混合类型），优先用显式ON条件 - 真正影响性能的是驱动表选择+连接字段索引，而不是JOIN写法本身
EXPLAIN里看到的驱动表是否合理、Rows_examined是否爆炸、右表条件到底该放ON还是WHERE。这些点错一个，结果就偏了。
