三张表JOIN必须为每个JOIN写全ON条件，否则会引发笛卡尔积；混合LEFT/INNER JOIN需用括号明确执行顺序；驱动表应按数据量从小到大排列；复杂多表关联优先用CTE分层处理。
三张表JOIN必须写全ON条件，漏一个就变笛卡尔积
不加ON的JOIN等于自找麻烦——MySQL不会报错，但结果集会指数级膨胀。比如users（1万行）、orders（5万行）、products（2千行）三表没写任何ON，结果就是1万 × 5万 × 2千 = 1000亿行，查询直接卡死。
常见错误是只给前两个表写ON，第三个表靠WHERE硬凑：
SELECT * FROM users u JOIN orders o ON u.id = o.user_id JOIN products p -- 这里漏了ON！ WHERE o.product_id = p.id;
这在语法上合法，但执行逻辑变成先做users × orders笛卡尔积，再用WHERE过滤，性能灾难。
- 每个
JOIN关键字后面必须紧跟一个ON（或USING）子句 -
ON必须明确指向两张表之间的关联字段，不能跨表引用（比如u.id = p.user_id这种中间无路径的写法无效） - 别名要一致：一旦给
orders起了别名o，后续所有地方都得用o.product_id，不能突然写成orders.product_id
混合LEFT JOIN和INNER JOIN时，括号不是可选，而是必需
当你要保留用户列表（即使没下单），但又只取有效商品（跳过下架品），就会出现LEFT JOIN后接INNER JOIN的组合。这时数据库默认从左到右执行：(users LEFT JOIN orders) INNER JOIN products，结果是：只要某用户没订单，整行被INNER JOIN products干掉——LEFT语义彻底失效。
正确做法是用括号锁住左连接范围：
SELECT u.name, o.order_no, p.name FROM users u LEFT JOIN (orders o INNER JOIN products p ON o.product_id = p.id) ON u.id = o.user_id;
- 括号内先完成
orders和products的严格匹配，生成“有效订单+商品”中间集 - 再用这个中间集与
users做LEFT JOIN，确保用户不丢 - MySQL 8.0+ 支持这种写法，但低版本可能报错，需确认实际环境
四张表以上JOIN，驱动表顺序直接影响查询速度
MySQL主要靠Nested Loop Join算法执行多表连接，外层循环次数 = 驱动表行数。如果把100万行的users放最前面，后面每连一张表都要循环100万次；换成10万行的orders打头，外层循环直接少90%。
别依赖优化器自动选驱动表——它常被WHERE条件干扰而选错。你得自己按数据量从小到大排表：
- 先查各表预估行数：
SELECT COUNT(*) FROM table_name - 把最小的表（如
categories通常几百行）放在FROM后第一位 - 中间表（如
products几万行）居中 - 最大表（如
orders百万级）尽量靠后，且前面要有强过滤条件（如WHERE o.created_at > '2026-07-01'）把它压到几千行再参与JOIN
超过四张表的JOIN，优先考虑CTE拆解而非硬链
五张表链式JOIN不是语法错误，但维护性极差：改一个关联字段，要检查5处ON；加个新过滤条件，得判断该放ON还是WHERE；EXPLAIN看执行计划时，嵌套层级深到没法定位瓶颈。
用WITH把逻辑分层更可控：
WITH active_orders AS ( SELECT o.id, o.user_id, o.created_at FROM orders o WHERE o.status = 'paid' AND o.created_at > '2026-07-01' ), user_order_items AS ( SELECT ao.*, oi.product_id FROM active_orders ao JOIN order_items oi ON ao.id = oi.order_id ) SELECT u.name, p.name, uoi.created_at FROM user_order_items uoi JOIN users u ON uoi.user_id = u.id JOIN products p ON uoi.product_id = p.id;
这样每段只处理2–3张表，字段来源清晰，中间结果可复用，也方便单独测试每层逻辑是否正确。
真正难的不是写出五表JOIN，而是判断哪张表不该出现在这里——比如分类名称本可由应用层缓存，硬塞进SQL只会拖慢主查询。业务语义比语法正确更重要。
