count(*)在left join后不能反映“未匹配”数量，因为它统计的是连接后全部行数（含右表null行），结果恒等于左表行数；应使用count(右表主键)判别是否匹配，或用where o.id is null直接筛选未匹配行。
LEFT JOIN后COUNT(*)为什么不能反映“未匹配”数量
COUNT(*)统计的是JOIN之后生成的全部行数，不是“匹配与否”的状态。LEFT JOIN会保留左表所有行，哪怕右表没匹配上，也会补一整行NULL字段——这一行仍被COUNT(*)计入，结果永远等于左表总行数。比如用户表100行，订单表为空，COUNT(*)返回100，而非你想要的“100条未匹配记录”。
用COUNT(右表主键)判别未匹配更可靠
真正能区分“匹配”和“未匹配”的是COUNT(右表主键)：主键天然非NULL，没匹配时该字段为NULL，COUNT(o.id)自动跳过这些NULL值，只统计成功关联的行数。
- 若
COUNT(o.id) = 0，说明该左表行在右表中无匹配 - 若
COUNT(o.id) > 0，说明至少有一条匹配 - 必须确保字段是主键或明确NOT NULL，否则
COUNT(o.status)会漏掉status为NULL的有效记录 - 示例：
SELECT u.id, COUNT(o.id) AS matched_count FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id
直接统计未匹配行总数：WHERE + IS NULL
如果目标不是逐行标记，而是算出“左表中有多少行在右表完全没匹配”，最直白的做法是过滤+计数：
- 写法：
SELECT COUNT(*) FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.id IS NULL - 关键点：条件必须放
WHERE，不能放ON；必须用IS NULL，不能写= NULL - 优先选右表主键（如
o.id）或外键字段（如o.user_id）判断，避免用可空业务字段（如o.tracking_no），否则无法区分“真未匹配”和“匹配了但字段为空” - 性能依赖右表连接字段是否有索引——没索引时
WHERE o.id IS NULL可能触发全表扫描
大数据量下避免中间结果膨胀
当右表存在一对多关系（例如一个用户对应上千条日志），直接LEFT JOIN再WHERE ... IS NULL会导致中间结果集爆炸，内存和IO压力陡增。
- 更稳的解法是预聚合右表：先用子查询或CTE把右表按关联字段去重或压缩，例如
(SELECT DISTINCT user_id FROM orders) o，再LEFT JOIN - 如果只需判断“有/无”，
NOT EXISTS往往比LEFT JOIN + IS NULL更快，尤其右表无索引时 - MySQL 8.0+ 和 PostgreSQL 对
IS NULL支持索引扫描，但SQLite或旧版MySQL可能退化为全表扫描 - 真正容易被忽略的，是默认把
COUNT(*)当成“业务意义上的未匹配数”——它只忠于SQL标准里的行计数语义，不替你理解“未匹配”到底指什么
