LEFT JOIN 的 ON 条件写成恒真表达式（如1=1）会导致全表返回，退化为CROSS JOIN；ON中误放左表过滤条件、右表字段大量NULL或类型不匹配、旧版MySQL谓词下推缺陷等，均会造成连接失效假象。
LEFT JOIN 的 ON 条件写成恒真表达式（如 1=1）
这是最直接导致“全表返回”的原因。ON 后跟 1=1、TRUE 或空条件，数据库无法做任何有效匹配，只能退化为 CROSS JOIN —— 左表每行都与右表所有行组合。
常见错误场景：
- 调试时临时注释掉连接条件，只留
ON 1=1，忘记还原 - 动态 SQL 拼接逻辑缺陷，当某字段为空时生成了
ON u.id = u.id这类自等式 - ORM 框架生成语句时，因参数未传入，把
ON u.id = ?变成了ON 1=1
验证方法：用 EXPLAIN 看执行计划，若出现 Nested Loop (Join Filter: true)（PostgreSQL）或 type: ALL + Extra: Using join buffer（MySQL），基本可确认。
ON 中混入了本该在 WHERE 的左表过滤条件
ON 子句只能引用它左侧所有表和右侧那个表，不能跨层、也不能“预筛”左表。如果你写了类似：
SELECT * FROM users u LEFT JOIN orders o ON u.id = o.user_id AND u.status = 'active'
这个 u.status = 'active' 并不会提前过滤 users 表 —— 它只是让 ON 判断多了一个条件，但 LEFT JOIN 仍会拉出所有 users 行，再逐行尝试匹配 orders。结果就是：左表没少，右表没连上，还多了一堆 NULL。
真正想筛左表，必须用 WHERE：
SELECT * FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.status = 'active'
右表关联字段大量为 NULL 或类型不匹配
ON 条件看似写了，比如 u.id = o.user_id，但若 o.user_id 有大量 NULL，或两边字段类型隐式转换（如 VARCHAR vs BIGINT），数据库可能无法使用索引，转而走全表扫描 + 嵌套循环，最终效果接近“遍历右表每行去比对”，看起来像“没过滤”。
关键点：
-
NULL = anything永远返回UNKNOWN，不满足 ON 条件，但 LEFT JOIN 仍保留左表行 —— 所以你看到的是“左表全在，右表全 NULL”，不是“全表连接” - 如果是“行数爆炸”，比如 100 行 × 1000 行 = 10 万行，那更可能是右表重复值 + 关联字段无唯一约束，而非 ON 失效
- 用
SELECT COUNT(*) FROM orders WHERE user_id IS NULL快速检查 NULL 比例
MySQL 旧版本对 ON 中复杂条件的兼容性问题
MySQL 5.7 及更早版本对 ON 子句中非关联字段的表达式支持较弱。例如：
LEFT JOIN orders o ON u.id = o.user_id AND o.created_at > '2025-01-01'
某些情况下，优化器可能忽略 o.created_at 条件，或把它延迟到 JOIN 后执行，导致右表实际未被提前过滤。这不是语法错误，而是执行计划退化。
应对方式：
- 升级到 MySQL 8.0+，支持更好的谓词下推
- 改用子查询预过滤右表：
(SELECT * FROM orders WHERE created_at > '2025-01-01') o - 避免在 ON 中写范围条件，除非该字段有高选择性且已建索引
真正容易被忽略的，是 ON 条件的“作用域”——它只决定“哪些右表行能参与连接”，不决定“哪些左表行该出现”。LEFT JOIN 的左表完整性是无条件的，哪怕 ON 里什么都没写，左表也全出来。所谓“没生效”，往往是你误以为它该筛左表，或者根本没写对连接逻辑。
