MySQL 5.7+和PostgreSQL对无ON的JOIN直接报错，SQLite和旧版MySQL则静默执行笛卡尔积；外键列类型不一致、LEFT JOIN后WHERE误用、复合主键漏字段等均导致隐性逻辑错误。
JOIN没加ON条件直接报错还是静默出错？
MySQL 5.7+ 和 PostgreSQL 会直接拒绝执行 SELECT * FROM a JOIN b 这种没写 ON 或 USING 的语句，报错 ERROR 1064 或 syntax error at or near "join"；但 SQLite 和旧版 MySQL（5.6 及更早）会默认做笛卡尔积——不报错，数据量稍大就卡死或返回百万行。别等上线才发现。
- 永远显式写
ON，哪怕只是临时调试也别省 - 用
EXPLAIN看执行计划：如果rows列数字异常大，且没出现key字段，大概率漏了关联条件 - 开发环境开 SQL 模式
STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY，能提前拦截弱约束写法
外键列类型不一致导致JOIN失效
user.id 是 BIGINT UNSIGNED，order.user_id 却是 INT，MySQL 会隐式转成有符号整型再比对，超出范围的值全变成 NULL，结果就是 JOIN 匹配不上——查不到数据，也不报错，只默默丢掉记录。
- 检查两边字段的完整类型：包括是否
UNSIGNED、NOT NULL、字符集（如utf8mb4_binvsutf8mb4_general_ci） - 用
SHOW CREATE TABLE对比，别只看字段名 - 迁移或建表脚本里，外键列必须和主表主键“字节级一致”，尤其注意 ORM 自动生成的 ID 类型（比如 Django 的
AutoField默认是INT，而BigAutoField才是BIGINT）
LEFT JOIN 后 WHERE 条件误写成过滤左表字段
写成 SELECT * FROM user LEFT JOIN order ON user.id = order.user_id WHERE order.status = 'paid'，实际效果等同于 INNER JOIN：因为 WHERE 在 JOIN 之后执行，order.status 为 NULL 的用户行全被干掉了。
- 想保留所有用户，把过滤条件挪到
ON子句：LEFT JOIN order ON user.id = order.user_id AND order.status = 'paid' - 如果必须用
WHERE，改用IS NULL或IS NOT NULL判断关联是否存在，而不是依赖非空字段值 - PostgreSQL 对此更敏感，某些版本会警告
possibly null-aware predicate
复合主键/外键场景下ON条件漏字段
订单明细表 order_item 用 (order_id, sku_id) 当主键，关联订单表时只写 ON order_item.order_id = order.id，漏了 sku_id —— 数据库不会报错，但每条订单可能匹配到 N 个重复 sku_id，结果行数爆炸。
- 复合键关联必须全部字段写进
ON，顺序无关，但字段名和数量不能少 - 建外键约束时，数据库会强制校验字段数量和顺序，但 JOIN 查询本身不依赖外键定义，所以即使没建外键，也要人工核对
- 用
SELECT COUNT(*)+GROUP BY快速验证：比如SELECT order_id, COUNT(*) FROM order_item GROUP BY order_id HAVING COUNT(*) > 1，看有没有意外重复
笛卡尔积不是性能问题，是逻辑错误。它往往藏在多表 JOIN 的第三层以后，或者动态拼 SQL 时字符串拼错了位置。上线前跑一次 EXPLAIN FORMAT=JSON，重点盯 rows_examined_per_scan 和 using_join_buffer 这两项，比测数据更早发现问题。
