每个JOIN后必须紧跟有效ON子句，否则必触发笛卡尔积；右表过滤条件须写在ON而非WHERE；子查询作表时仍需真实ON关联；多表JOIN需确保每对相邻表都有业务意义的连接条件。
只要JOIN后面没写有效ON子句，或者写了但条件没约束力，笛卡尔积就不是“可能”，而是“一定发生”——尤其当订单表10万行、客户表5万行时，结果集直接奔着50亿去，查询卡死或OOM是常态。
每个JOIN后必须紧跟有效的ON子句
MySQL 8.0+ 会直接报ERROR 1064，但旧版（如5.7）在宽松模式下会静默退化为CROSS JOIN，你根本收不到错误提示。
- 检查每个
JOIN关键字后是否紧跟着ON，而不是空着、写成WHERE、或用USING却字段名不一致 - 字段名拼错（如
orders.cust_id应为orders.customer_id）会导致该字段值全为NULL，NULL = customers.id恒为FALSE，优化器放弃索引，最终效果等同于无条件连接 - Linux系统下注意大小写：
customer_id≠Customer_ID；反引号包错字（如`cusotmer_id`）语法合法但语义错误
LEFT JOIN的右表过滤条件必须写进ON，不能放WHERE
WHERE是在连接完成后再筛选，而ON控制连接过程本身。把右表条件塞进WHERE，等于先生成全部NULL匹配行，再一刀砍掉——逻辑错、性能差、还浪费资源。
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 错误写法：
LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active'→ 所有无客户匹配或状态非 active 的订单全丢，实际退化为INNER JOIN - 正确写法：
LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active'→ 左表行数不变，只拉活跃客户 - 若业务真要“所有订单 + VIP用户信息”，
WHERE里绝不能出现c.level这类右表字段；对右表做IS NOT NULL判断也等效于INNER JOIN
子查询作表时仍需真实ON关联，不能靠“内部已聚合”蒙混过关
子查询一旦出现在FROM或JOIN右侧，它就是一张临时表，和外层之间仍需业务意义明确的ON条件。漏掉或写成ON 1=1，等于裸连大表。
- 危险写法：
LEFT JOIN (SELECT order_id, SUM(amount) FROM payments GROUP BY order_id) b ON 1=1→ 等效于没限制 - 安全写法：
LEFT JOIN (SELECT order_id, SUM(amount) AS total FROM payments GROUP BY order_id) b ON a.id = b.order_id - 若子查询不含外层可关联字段（如没
order_id），就不能直接JOIN，应改用标量子查询或EXISTS
多表JOIN必须逐对验证“桥接链”是否完整
三张及以上表连接时，不能只确保首尾两张表有关联，中间每一对相邻表都得有真实业务意义的ON条件。跳过中间实体强行连接，数据库只能暴力匹配。
- 错误链路：
orders JOIN products ON orders.id = products.id（无此业务逻辑）→orders和products行数相乘，order_items形同虚设 - 正确链路：
orders JOIN order_items ON orders.id = order_items.order_id JOIN products ON order_items.product_id = products.id - 快速验证：对每个
JOIN后的中间结果加LIMIT 5查看行数是否合理；某步后行数突增数十倍，大概率断链了
最容易被忽略的是：连接字段本身的数据质量。哪怕ON写得完全正确，orders.customer_id有100个NULL、或customers.id = 123对应3条记录（软删除未清理），结果集照样指数级膨胀——这不是SQL写错了，是数据逻辑冗余在咬你。
