LEFT JOIN后WHERE中使用右表字段会导致左表无匹配记录被过滤，因WHERE在ON之后执行，应将匹配约束条件移至ON子句，筛选条件才保留在WHERE。

LEFT JOIN后WHERE里用了右表字段，结果变少了

这是最典型的信号：你本想保留左表全部记录，但最终结果却只返回了部分——说明WHERE条件无意中过滤掉了右表为NULL的行。比如写WHERE o.status = 'paid'，而o.status来自右表orders，那些没订单或订单状态不是paid的用户就全被踢掉了。

根本原因在于执行顺序：ON先决定怎么连，WHERE后筛结果。一旦WHERE里出现对右表字段的非IS NULL判断，所有右表字段为NULL的行（即左表无匹配）都会被干掉。

• 检查WHERE子句里是否包含右表字段的等值、范围或IN判断（如o.amount > 100、o.type IN ('A','B')）
• 若该条件本意是“只关联满足此条件的右表数据”，必须挪到ON里，加AND
• 若该条件本意是“只保留右表有值且满足此条件的行”，那WHERE是对的，但你要清楚这已不是纯LEFT JOIN语义了

右表条件该放ON还是WHERE？看它是否影响左表留存

一句话判断标准：这个条件是用来缩小右表匹配范围，还是用来筛选最终结果？

比如要查“所有用户及其2023年订单”，目标是“所有用户”必须在——那order_time BETWEEN '2023-01-01' AND '2023-12-31'就是匹配约束，得放ON；但如果目标是“只看2023年有订单的用户”，那它就是结果筛选，放WHERE也合理。

• 放ON：条件作用于右表参与连接的行集合，不影响左表行数
• 放WHERE：条件作用于连接后的整行，可能剔除左表行（只要右表字段不满足）
• 例外：用WHERE o.id IS NULL是合法且常见操作，用于找左表中“没有匹配右表”的记录

多表LEFT JOIN时，每个ON都要独立考虑右表条件

别以为第一个LEFT JOIN写对了，后面就安全了。每层JOIN的ON都是独立作用域，右表条件漏写或错放，照样破坏语义。

例如：users LEFT JOIN orders ON users.id = orders.user_id LEFT JOIN order_items ON orders.id = order_items.order_id AND order_items.qty > 0——这里qty > 0放在第二层ON是对的，因为它限制的是order_items哪些行参与连接；但如果写成WHERE order_items.qty > 0，就会把“订单存在但所有商品数量≤0”的用户也过滤掉。

• 逐个检查每个LEFT JOIN后的ON子句，确认是否包含了该右表应有的业务约束
• 避免在WHERE里跨层引用深层右表字段（如WHERE order_items.price > 10），除非你明确接受因此丢失左表行
• 复杂场景下，优先用子查询提前过滤右表（如LEFT JOIN (SELECT * FROM order_items WHERE qty > 0) oi ON ...），逻辑更清晰

调试时快速验证LEFT JOIN是否被WHERE破坏

最直接的办法：临时注释掉WHERE，只留SELECT *和JOIN，观察左表行数是否与原始左表一致。再逐步加回WHERE条件，看哪一条开始减少行数。

• 用COUNT(*)对比：先查SELECT COUNT(*) FROM users，再查带LEFT JOIN但无WHERE的COUNT(*)，两者应相等
• 查NULL占比：加WHERE o.id IS NULL看有多少用户没订单；再加其他条件，如果这个数字归零，说明WHERE正在吃掉这些行
• 别依赖EXPLAIN输出判断逻辑正确性——它只告诉你怎么执行，不告诉你结果对不对

实际写SQL时，真正容易被忽略的不是语法，而是每一处右表字段引用背后隐含的语义承诺：你到底还想不想让左表那些“没匹配上”的记录出现在结果里。