LEFT JOIN 后 COUNT() 不能判断“从未下单”，因为未匹配的用户不生成分组行，COUNT() 至少为1；应使用 WHERE 右表外键 IS NULL 判断，如 o.customer_id IS NULL。
LEFT JOIN 后 COUNT(*) 为什么不能判断“从未下单”
直接写 LEFT JOIN 再用 COUNT(*) = 0 筛用户，结果永远为空。因为 GROUP BY 只对实际参与连接的行分组，而“没订单”的用户在右表（orders）里根本没记录，不会生成任何分组行，更谈不上 HAVING COUNT(*) = 0 生效。
常见错误写法：SELECT c.id FROM customers c LEFT JOIN orders o ON c.id = o.customer_id GROUP BY c.id HAVING COUNT(*) = 0
它查不到任何结果——不是语法错，是逻辑断层：没匹配的行压根不进分组流程。
-
COUNT(*)统计的是当前分组内的行数，只要该用户出现在结果集中（哪怕右表全为NULL），这行就存在，COUNT(*)至少为 1 - 想表达“无订单”，必须依赖右表字段是否为
NULL，而不是靠聚合值“等于 0” - 真正要统计的不是“行数为 0”，而是“右表关键字段未命中”
正确写法：LEFT JOIN + WHERE 右表关联字段 IS NULL
核心是先保留所有用户，再识别哪些人的订单字段没被填充。关键在 WHERE 条件写对字段——必须用右表的外键字段（如 o.customer_id），而不是主键（如 o.id）。
正确示例：SELECT c.id, c.name FROM customers c LEFT JOIN orders o ON c.id = o.customer_id WHERE o.customer_id IS NULL;
- 必须用
o.customer_id IS NULL：这是左连接后右表未匹配的明确标志 - 不能用
o.id IS NULL：如果订单表允许customer_id为NULL，这条条件会把脏数据也混进来 - 不需要
GROUP BY：这不是聚合场景，是存在性判断，单条记录即代表一个“从未下单”用户 - 若业务真要附带统计（比如按注册月份分组看各月流失情况），才在外部套一层
GROUP BY，但判断逻辑仍在WHERE层
非要 GROUP BY 的场景下怎么安全统计？
比如报表要求同时输出“有订单用户数”和“无订单用户数”，这时需要分组上下文，但不能硬套 HAVING COUNT(*) = 0。
推荐用子查询或 NOT EXISTS 配合主表分组：SELECT COUNT(*) AS total_customers, COUNT(CASE WHEN NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id) THEN 1 END) AS no_order_count FROM customers c;
-
NOT EXISTS比NOT IN更安全：不惧orders.customer_id中出现NULL - 避免在
GROUP BY中直接依赖LEFT JOIN后的COUNT(*)做真假判断——它无法区分“0 笔订单”和“1 行空连接” - 如果必须用
LEFT JOIN做分组统计，可用COUNT(o.customer_id)：这个值在无匹配时为 0（因o.customer_id是NULL，COUNT忽略），比COUNT(*)语义清晰
容易被忽略的 NULL 和索引细节
线上查得慢、结果偶尔不对，往往卡在这两个地方。
-
orders.customer_id字段如果没有索引，LEFT JOIN或NOT EXISTS都会触发全表扫描，大表上秒变分钟级 - 如果
customers.id是VARCHAR而orders.customer_id是INT，隐式类型转换会让索引失效，务必保持类型一致 -
WHERE o.customer_id IS NULL这个条件本身无法走索引（IS NULL在多数引擎中不利用 B-Tree 索引），所以性能关键其实在左连接前的驱动效率，而非这个WHERE - 测试时用
EXPLAIN看type是否为ref或eq_ref，key是否命中预期索引——别只看结果对不对
