LEFT JOIN后COUNT(*)总是1，是因为它统计连接结果的行数，左表每行至少生成一行（右表无匹配时补NULL），而非右表有效记录数；应改用COUNT(右表非空字段)并配合COALESCE确保0值。
为什么LEFT JOIN后COUNT(*)总是返回1？
因为LEFT JOIN会保留左表所有行，即使右表无匹配，也会补NULL生成一行。此时COUNT(*)统计的是连接后的结果行数，不是左表原始行数，更不反映右表真实关联数量。
常见错误写法：
SELECT a.id, COUNT(*) FROM orders a LEFT JOIN order_items b ON a.id = b.order_id GROUP BY a.id;——这会让无子项的订单也返回
COUNT(*) = 1（因LEFT JOIN生成了a行 + b为NULL的一行）。
- 想统计每个订单有多少商品，必须用
COUNT(b.id)或COUNT(b.order_id)，跳过NULL -
COUNT(*)和COUNT(1)行为一致，都算行数；只有COUNT(列名)才忽略NULL - 如果右表有重复关联（比如用非主键/非唯一字段JOIN），
COUNT(b.id)会放大计数，需先去重或改用子查询
如何正确统计“每个订单的商品数量”，包括0？
核心是：用LEFT JOIN保左表，用COUNT(右表非空列)算有效关联数。
正确写法：
SELECT a.id, COUNT(b.order_id) AS item_count FROM orders a LEFT JOIN order_items b ON a.id = b.order_id GROUP BY a.id;
-
COUNT(b.order_id)对每组中b.order_id为NULL的行不计数，所以无商品的订单得到0 - 确保
b.order_id在order_items中允许NULL（通常不会，但显式用它比用b.id更语义清晰） - 如果
order_items里存在脏数据（如order_id为NULL），这些行会被LEFT JOIN过滤掉（因ON条件不成立），不影响结果
遇到多对多JOIN时COUNT翻倍怎么办？
当左表与右表是多对多关系（例如一个订单有多个商品，一个商品又被多个订单购买），直接JOIN再COUNT会导致笛卡尔积，数量严重失真。
典型场景：查每个用户下的订单数 + 这些订单里的总商品种类数（需跨两个一对多关系）。
- 别在一个查询里连三张表后
COUNT(DISTINCT c.category_id)——容易因中间表膨胀导致内存/性能问题 - 优先用子查询分别聚合：
SELECT u.id, COALESCE(o.order_cnt, 0) AS order_count, COALESCE(i.item_cat_cnt, 0) AS category_count FROM users u LEFT JOIN (SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id) o ON u.id = o.user_id LEFT JOIN (SELECT o2.user_id, COUNT(DISTINCT i2.category_id) AS item_cat_cnt FROM orders o2 JOIN order_items i2 ON o2.id = i2.order_id GROUP BY o2.user_id) i ON u.id = i.user_id; - 如果数据库支持窗口函数（如PostgreSQL、MySQL 8.0+），也可用
COUNT(...) OVER (PARTITION BY ...)避免多次扫描
MySQL中COUNT(*) vs COUNT(1) vs COUNT(主键)性能有区别吗？
在大多数现代MySQL版本（尤其是InnoDB）中，三者执行计划几乎一致，优化器都会选择最小可用索引（通常是主键）扫行，性能差异可忽略。
-
COUNT(*)是SQL标准语法，语义最清晰，推荐首选 -
COUNT(1)和COUNT(*)在MySQL中完全等价，但某些旧版驱动或ORM可能对COUNT(1)解析异常 -
COUNT(主键)在语义上强调“非空列”，但若主键被定义为NOT NULL（通常如此），效果同COUNT(*)；若误写成COUNT(普通列)且该列允许NULL，就可能漏计 - 真正影响性能的是是否走索引、是否需要回表、以及是否有
WHERE条件导致索引失效——而不是COUNT括号里写啥
COUNT(*)、COUNT(右表列)还是COUNT(DISTINCT 右表列)——选错一个词，结果就差几倍。 
