left join后count(*)总是1是因为它统计连接后每行（含右表null行），而非右表有效记录数；应改用count(右表主键)并配合group by左表主键，左表过滤条件须写在where而非on子句。
LEFT JOIN后COUNT(*)为什么总是1？
因为COUNT(*)统计的是结果行数，哪怕右表没匹配到也会生成一行（NULL填充），所以它永远不为0。真正要统计“某类关联记录数量”，必须用COUNT(右表主键)或COUNT(右表非空字段)——只有该字段为NULL时才不计数。
常见错误写法：
SELECT a.id, COUNT(*) FROM orders a LEFT JOIN items b ON a.id = b.order_id GROUP BY a.id这会把每个订单都算作1条，哪怕它没任何商品。
正确做法是：
SELECT a.id, COUNT(b.id) FROM orders a LEFT JOIN items b ON a.id = b.order_id GROUP BY a.id此时
b.id为NULL的行被COUNT忽略，自然得到0。
GROUP BY漏写或错写字段导致聚合混乱
LEFT JOIN + 聚合必须明确GROUP BY左表的主键（或唯一标识列）。如果漏写、多写右表字段，或者用非唯一字段分组，结果要么报错（严格模式），要么逻辑错乱。
关键原则：GROUP BY 的字段必须能唯一确定左表每一行，且不能包含右表可能为NULL的字段。
- ✅ 正确：
GROUP BY a.id（假设a.id是orders主键） - ❌ 错误：
GROUP BY a.status（多个订单可能同状态，会被合并） - ❌ 危险：
GROUP BY a.id, b.category（b.category为NULL时分组不稳定）
需要WHERE过滤左表时，条件不能写在ON里
如果只想统计“2024年下的订单及其商品数”，把时间条件放在ON子句里会改变LEFT JOIN语义：它会让右表匹配失效，但左表行仍保留——可结果却把非2024年的订单也拉进来（只是商品数为0），违背本意。
正确方式是把左表过滤条件放到WHERE中：
SELECT a.id, COUNT(b.id) FROM orders a LEFT JOIN items b ON a.id = b.order_id WHERE a.created_at >= '2024-01-01' GROUP BY a.id
若误写成ON a.id = b.order_id AND a.created_at >= '2024-01-01'，则a.created_at实际未过滤左表，所有订单都会参与JOIN，仅影响右表匹配逻辑——这是隐蔽的逻辑陷阱。
性能敏感场景下COUNT(b.id)比COUNT(*)慢？
理论上COUNT(*)走索引行计数最快，COUNT(b.id)需判NULL，但现代数据库（PostgreSQL 12+、MySQL 8.0+、SQL Server）对COUNT(非空列)做了优化，只要b.id定义为NOT NULL，执行计划通常和COUNT(*)一致。
真正影响性能的是JOIN本身——如果右表数据量大且缺乏order_id索引，LEFT JOIN会变慢。务必确认右表JOIN字段有索引：
- MySQL：
ALTER TABLE items ADD INDEX idx_order_id (order_id); - PostgreSQL：
CREATE INDEX CONCURRENTLY ON items (order_id);
没有这个索引，零数量统计可能从毫秒级变成秒级，而且越查越慢。
