多表JOIN应优先让高选择性表或小表在前以控制中间结果集大小，避免LEFT JOIN后在WHERE中过滤右表字段导致逻辑错误，且跨库/引擎JOIN需确保字段类型、字符集严格一致。
三表JOIN时顺序错乱导致结果膨胀
多表JOIN不是按书写顺序执行的，数据库优化器会重排顺序，但你写的顺序会影响中间结果集大小。如果先JOIN两个大表再连小表，可能生成百万级临时行，哪怕最终WHERE里有强过滤条件也晚了。
实操建议：
- 用EXPLAIN看实际执行计划，重点看rows列和type（避免ALL）
- 把带高选择性过滤条件的表（比如带WHERE user.status = 'active'的表）尽量放在JOIN链开头
- 如果必须按业务逻辑写顺序，加STRAIGHT_JOIN（MySQL）或/*+ ORDERED */（Oracle）强制顺序，但要确认统计信息最新
- 小表驱动大表仍是有效经验：先JOIN主键明确、行数少的维度表（如product_category），再连事实表（如order_items）
子查询嵌套过深引发性能雪崩
三层以上SELECT ... FROM (SELECT ... FROM (SELECT ...))结构，不仅可读性差，更致命的是很多数据库无法下推外层WHERE到内层，导致全量计算中间结果。
实操建议：
- 把WHERE条件尽可能提到最外层，避免在子查询里写WHERE 1=1再靠外层过滤
- 能用JOIN替代的IN (SELECT ...)必须换掉——特别是子查询返回NULL时，IN直接失效，而JOIN天然排除NULL
- 对于需要聚合后再关联的场景，优先用CTE（WITH子句）而非嵌套子查询，便于数据库复用中间结果
- PostgreSQL和MySQL 8.0+支持LATERAL，适合“每行调用一次子查询”的场景，比传统相关子查询高效得多
LEFT JOIN + WHERE条件误写成INNER效果
这是线上事故高频点：在LEFT JOIN后，对右表字段加WHERE条件（如WHERE b.status = 'paid'），实际上把左连接变成了内连接——因为NULL值被WHERE过滤掉了。
实操建议：
- 右表的过滤条件必须写在ON子句里，而不是WHERE里
- 如果确实需要保留左表全部记录，同时只取右表特定状态，写成：LEFT JOIN b ON a.id = b.a_id AND b.status = 'paid'
- 检查执行计划中Extra列是否出现Using where且涉及右表字段，那是危险信号
- 用IS NULL判断右表未匹配时，必须确保该字段本身允许NULL，否则LEFT JOIN失去意义
跨库/跨引擎JOIN导致隐式转换失败
当JOIN涉及不同存储引擎（如InnoDB + MyISAM）或不同字符集（utf8mb4 vs utf8）的表时，数据库可能静默转换字段类型，导致索引失效或结果错误。
实操建议：
- 连接字段必须严格一致：类型（VARCHAR(50) ≠ TEXT）、字符集（utf8mb4_unicode_ci ≠ utf8_general_ci）、排序规则（collation）
- 用SHOW CREATE TABLE逐个核对字段定义，别信ORM生成的SQL注释
- 分布式场景（如TiDB、ShardingSphere）下，跨分片JOIN基本不可控，优先改用应用层两次查询+内存合并
- MySQL中STRAIGHT_JOIN无法跨库，遇到ERROR 1105 (HY000): unknown error: can't find table大概率是库名/表名大小写或路径问题
真正卡住人的从来不是语法会不会写，而是执行计划里那个没注意的Using temporary; Using filesort，或者ON和WHERE之间差的一个空格。
