直接用select user_id, count(*) as order_count from orders group by user_id统计每个用户订单数，需注意user_id是否为空、是否需去重、关联用户信息时的连接方式及过滤条件位置。
用 GROUP BY 和 COUNT() 统计每个用户的订单数
直接对 orders 表按用户字段分组，再用 COUNT() 聚合即可。关键不是“怎么写”，而是“按哪个字段分组”和“要不要去重”——比如一个用户可能有多个同名账户或匿名下单，得先确认数据模型。
- 最常见写法：
SELECT user_id, COUNT(*) AS order_count FROM orders GROUP BY user_id - 如果
user_id可能为NULL（如游客订单），这条语句默认会把所有NULL归为一组；需要单独处理就加WHERE user_id IS NOT NULL - 若想统计“去重后的下单用户数”，别用
COUNT(*)，改用COUNT(DISTINCT user_id)——但这是全表总数，不是每人一个值，不能和GROUP BY混用
用户信息缺失时怎么关联补全姓名或邮箱
纯 orders 表通常只有 user_id，要显示用户名就得 JOIN users。但要注意左连接还是内连接：如果允许订单归属“已删除用户”，就得用 LEFT JOIN，否则会丢掉那些记录。
- 安全写法：
SELECT o.user_id, u.name, COUNT(*) AS order_count FROM orders o LEFT JOIN users u ON o.user_id = u.id GROUP BY o.user_id, u.name - 必须同时
GROUP BY所有非聚合字段（如u.name），否则 MySQL 8.0+ 或 PostgreSQL 会报错 - 如果
users表里有重复id（脏数据），JOIN后会导致订单数虚高——先查SELECT id, COUNT(*) FROM users GROUP BY id HAVING COUNT(*) > 1
统计结果里排除测试订单或已取消订单
真实场景中，status 字段直接影响业务口径。“已取消”算不算下单？“test_user”算不算真实用户？这些过滤条件必须在 WHERE 子句里完成，不能靠 HAVING。
- 正确位置：
WHERE status IN ('paid', 'shipped') AND user_id NOT LIKE 'test_%' - 错误做法：写成
HAVING status = 'paid'——HAVING只能过滤聚合后的结果，而status是行级字段，此时已不可见 - 索引建议：在
(user_id, status)上建联合索引，能加速带这两个条件的统计查询
大数据量下 COUNT(*) 很慢怎么办
当 orders 表超千万行，每次跑 COUNT(*) GROUP BY 都扫全表，前端点一下等五秒。这不是语法问题，是架构问题。
- 临时缓解：加覆盖索引，例如
CREATE INDEX idx_user_status ON orders(user_id, status)，让统计走索引而不回表 - 长期方案：用实时更新的汇总表，比如每笔订单插入时，同步更新
user_order_counts表里的order_count字段 - 警惕近似统计：某些数据库支持
APPROX_COUNT_DISTINCT()，但它不适用于“每人计数”，只适合全表去重总数
EXPLAIN 看一眼执行计划，特别是 type 是否为 index 或 range，而不是 ALL。索引建不对，写再漂亮的 SQL 也白搭。
