不指定关联键的join本质是笛卡尔积，易致性能崩溃；left join误将右表条件放where会使左表空匹配行丢失；on子句不可引用非直接连接表；字段名冲突须用别名，缺失索引会引发全表扫描与锁争用。
不指定关联键的JOIN，本质就是让数据库执行全表交叉组合——这不是语法错误，而是逻辑失控的起点。
ON条件为空或恒真时，直接生成笛卡尔积
比如写SELECT * FROM orders JOIN customers（没ON），或ON 1=1、ON t1.id IS NOT NULL，数据库不会报错，但会把两表所有行做乘积。1万行 × 1万行 = 1亿行结果，内存和IO瞬间吃紧。
- MySQL老版本可能静默转为
CROSS JOIN，PostgreSQL/SQL Server通常直接报错 -
EXPLAIN里看到type: ALL且rows列数值异常高（比如左表100行，右表扫描行数显示10000+），基本可确认 - 别信“数据量小所以没关系”——上线后表膨胀、并发一上来就卡死
LEFT JOIN中把右表过滤条件误放WHERE，等于悄悄删掉左表空匹配行
写LEFT JOIN servers ON racks.id = servers.rack_id WHERE servers.is_virtual = false，表面看只是筛虚拟机，实际会让所有servers为空的racks行被整行过滤掉——LEFT JOIN退化成INNER JOIN。
- 正确做法是把
servers.is_virtual = false塞进ON：LEFT JOIN servers ON racks.id = servers.rack_id AND servers.is_virtual = false - 验证方法：加
COUNT(*)对比，分别执行WHERE servers.id IS NOT NULL和去掉该条件，行数差异是否符合业务预期 - ORM（如GORM、MyBatis）生成的SQL常默认把过滤放WHERE，必须人工检查
多表JOIN时ON引用了未参与当前连接的表，条件被忽略或报错
SQL标准规定：ON子句只能引用当前JOIN左右两侧的表。写A JOIN B ON A.x = B.y JOIN C ON A.z = C.w AND B.u = C.v，在MySQL旧版本里B.u = C.v可能被静默丢弃；PostgreSQL则直接报column "b.u" does not exist。
- 三张表连查，推荐用括号明确结合顺序：
FROM A JOIN (B JOIN C ON B.id = C.b_id) ON A.id = B.a_id - 更稳妥的是用CTE预处理中间结果，避免嵌套层级过深导致语义模糊
- 字段名冲突时（比如两表都有
id），必须加表别名，否则ON id = id等价于ON TRUE
真正危险的不是报错，而是不报错却返回错误数据——尤其当关联键缺失索引时，全表扫描+间隙锁还会拖垮整个库的并发能力。
