left join查不到右表数据是因为where子句对右表字段的非空条件过滤了null行，应将右表筛选条件移至on子句；inner join查不到数据主因是连接字段类型/值不一致、null参与比较或大小写敏感；count(*)统计所有行，count(右表字段)仅统计非null值。
LEFT JOIN 为什么有时查不到右表数据
因为 LEFT JOIN 会保留左表所有行，但右表匹配不上时，对应字段全为 NULL——这不是“丢失”，而是设计行为。常见误判场景是：在 WHERE 子句里对右表字段加非空条件（比如 WHERE t2.status = 'active'），这会把 NULL 行直接过滤掉，结果等价于 INNER JOIN。
实操建议：
- 想保留左表全部记录，又需筛选右表数据，把右表条件移到
ON子句（如ON t1.id = t2.t1_id AND t2.status = 'active'） - 确认是否真需要左表“无匹配也显示”，否则优先用
INNER JOIN - 用
SELECT *初步调试时，注意观察右表字段是否批量为NULL，这是匹配失败的明确信号
INNER JOIN 查不到预期数据的三个典型原因
INNER JOIN 只返回两表都能匹配上的行，所以“查不到”往往不是语法错，而是逻辑不满足。最常踩的坑是连接字段类型或值不一致。
实操建议：
- 检查连接字段是否有隐式类型转换：比如
user_id左表是INT，右表是VARCHAR且含空格，'123 '≠123 - 确认 NULL 值参与连接：任何与
NULL的等值比较都返回UNKNOWN，不会被INNER JOIN匹配到 - 留意大小写敏感性：某些数据库（如 MySQL 默认
utf8mb4_0900_as_cs排序规则）下'ABC'≠'abc'
LEFT JOIN 后 COUNT(*) 和 COUNT(右表字段) 结果差很多
这是初学者最容易困惑的点：COUNT(*) 统计所有返回行数（包括右表为 NULL 的行），而 COUNT(t2.id) 只统计 t2.id 非 NULL 的行数——两者语义完全不同。
实操建议：
- 统计“左表有多少条有对应右表记录”，用
COUNT(t2.id)或COUNT(t2.some_not_null_column) - 统计“左表总共多少条”，无论右表是否匹配，用
COUNT(*)或COUNT(t1.id) - 如果右表主键允许
NULL（极少见），别依赖COUNT(t2.pk)判断关联存在性，改用SUM(CASE WHEN t2.pk IS NOT NULL THEN 1 ELSE 0 END)
什么时候必须用 LEFT JOIN，而不是强行用 INNER JOIN + UNION
有人试图用 INNER JOIN 拆成多个查询再拼结果，这不仅性能差，还会破坏行级关联关系。LEFT JOIN 不可替代的核心场景是：需以左表为基准做聚合或排序，同时携带可选的右表属性。
实操建议：
- 报表类需求（如“每个用户订单数，含零订单用户”）必须用
LEFT JOIN+COUNT(t2.order_id) - 多表级联时，若中间某表可能缺失（如用户→地址→城市→国家），用嵌套
LEFT JOIN比反复UNION清晰且可控 - 数据库优化器对单次
LEFT JOIN的执行计划通常优于多个子查询拼接，尤其涉及索引使用时
真正难的不是语法，是想清楚“哪张表该当主干、哪些关联是强制的、哪些是可选的”。一旦连业务语义都没理清，换什么 JOIN 都会出错。
