JOIN顺序不影响INNER JOIN语义，但影响执行计划；LEFT JOIN需区分ON与WHERE，隐式JOIN已过时；字段类型不一致会导致索引失效。
JOIN顺序影响执行计划，但不决定语义正确性
SQL里INNER JOIN的左右顺序不影响结果集（只要连接条件一致），但数据库优化器会据此生成不同执行计划——尤其当表大小差异大时。比如小表在前、大表在后，某些引擎（如MySQL 5.7）更倾向用小表做驱动表，减少嵌套循环次数。
常见错误现象：EXPLAIN显示type=ALL且rows暴增，实际是优化器选了大表当驱动表。
- 显式用
STRAIGHT_JOIN（MySQL）或/*+ LEADING() */（Oracle/PG）强制驱动顺序，仅在确认优化器误判时使用 - 避免把
LEFT JOIN的右表写成可能为空的宽表，否则可能导致索引失效和临时表膨胀 - PostgreSQL中
JOIN顺序对CBO影响较小，但LATERAL子查询必须严格按依赖顺序写
ON和WHERE混用导致LEFT JOIN语义丢失
LEFT JOIN的过滤逻辑必须拆清：连接条件放ON，过滤结果放WHERE。一旦把本该在ON里的条件挪到WHERE，就等价于INNER JOIN——空值行被直接筛掉。
使用场景：查所有用户及其订单数，包括0单用户。若写WHERE order.status = 'paid'，则没订单的用户全消失。
-
ON只管“怎么连”，WHERE管“连完留哪些” - 多表
LEFT JOIN时，后续ON可引用前面所有表的字段，但WHERE只能引用最终结果列 - MySQL 8.0+支持
USING语法简化等值连接，但无法用于复杂表达式，慎用于需要兼容老版本的项目
隐式JOIN（逗号语法）已过时且易出错
用FROM a, b WHERE a.id = b.a_id这种写法，本质是CROSS JOIN加WHERE过滤，既难读又容易漏条件——少写一个AND就变笛卡尔积。
性能影响：现代优化器虽能识别并转成INNER JOIN，但无法对隐式连接做谓词下推，可能延迟过滤时机，增加中间结果集体积。
- 所有新代码禁用逗号分隔表名，统一用显式
JOIN ... ON - 已有代码迁移时，注意检查
WHERE中是否混入了连接条件，需拆到对应ON子句 - SQL linter（如
sqlfluff）可配置规则自动报出from_without_join类问题
JOIN字段类型不一致引发隐式转换与索引失效
当ON a.user_id = b.user_id中两边字段类型不同（比如VARCHAR vs INT），MySQL会把数字转成字符串再比，导致b.user_id索引完全失效；PostgreSQL则直接报错或拒绝隐式转换。
常见错误现象：EXPLAIN里key列为NULL，Extra出现Using where; Using join buffer。
- 建表时保持关联字段类型、字符集、排序规则完全一致，尤其注意
VARCHAR(16)和CHAR(16)的区别 - 用
SHOW CREATE TABLE核对两边字段定义，别只看名字 - 对存量数据做类型修正时，优先用
ALTER TABLE ... MODIFY COLUMN而非CAST()函数包裹，后者无法走索引
JOIN不是写完就能跑通的语法糖，最麻烦的永远是那些不报错但结果不对、或者跑得越来越慢的边界情况——比如时间字段用DATETIME和TIMESTAMP混连，或者JSON字段里存ID还拿去JOIN。
