如何用 GROUP BY + 聚合函数做基础用户统计
直接对用户表按维度分组是最快出数的方式，比如按注册日期、地区、来源渠道统计人数。关键不是写 SELECT，而是想清楚
GROUP BY的字段是否和业务口径一致——比如「日活」必须用登录日志表的
DATE(login_time)，不能用用户表的
created_at。
常见错误：漏掉
WHERE过滤测试账号或无效数据。建议在统计前先加条件：
WHERE status = 1 AND is_test = 0。
COUNT(DISTINCT user_id)是计算去重用户的核心，别只用
COUNT(*)时间范围尽量用
BETWEEN '2024-01-01' AND '2024-01-31'，避免函数包裹字段（如
DATE(created_at)）导致索引失效 如果要算留存率，得先用子查询或 CTE 拿出首日用户集，再关联后续行为表——单条 SQL 很难兼顾准确性和可读性
怎么把多张表拼成一张宽表用于报表展示
报表前端常要求「一个用户一行，带注册时间、最近登录、总订单数、首单金额」这类字段，本质是把用户主表和日志、订单、支付等事实表做左连接。但 MySQL 对大表 JOIN 效率敏感，容易慢甚至 OOM。
推荐做法：用
LEFT JOIN配合子查询或聚合视图，而不是直接连原始明细表。例如查每个用户的最新登录时间，不要
JOIN login_log，而应先
SELECT user_id, MAX(login_time) AS last_login FROM login_log GROUP BY user_id再 JOIN。 所有 JOIN 字段必须有索引，尤其是
user_id和时间字段 避免在 JOIN 条件里写函数，比如
ON DATE(l.login_time) = DATE(u.created_at)会强制全表扫描 如果报表需高频访问，考虑用定时任务把宽表结果写入
report_user_summary这类汇总表，而非每次实时计算
遇到“内存溢出”或“执行超时”怎么调优
用户统计类 SQL 最容易在数据量上 100 万后开始变慢，报错通常是
MySQL server has gone away或
Lost connection to MySQL server during query，根本原因往往是临时表撑爆内存或排序缓冲区不足。
先看执行计划：
EXPLAIN FORMAT=JSON查是否有
Using temporary; Using filesort；再确认配置项：
sort_buffer_size、
tmp_table_size、
max_heap_table_size是否过小（默认通常只有 2MB–16MB）。 临时表超过
tmp_table_size就会落地磁盘，性能断崖下跌——可临时调高，但别设成几 GB，会影响并发 用
SQL_BIG_RESULT提示优化器优先走磁盘临时表，反而比强行内存排序更稳 分页统计慎用
LIMIT 100000, 20，改用基于游标的方案，比如
WHERE id > 123456 ORDER BY id LIMIT 20
为什么有些统计值和业务方对不上
最常被忽略的是时区和数据延迟。MySQL 默认用系统时区，但用户行为日志可能来自不同时区的服务器，
NOW()和
UTC_TIMESTAMP()结果能差 8 小时；另外，ETL 同步延迟、binlog 消费滞后、缓存未刷新都会让报表数字“看起来不准”。
解决思路不是反复改 SQL，而是明确每张表的数据更新 SLA。比如订单表 T+1 凌晨 2 点同步完成，那当天 10 点跑的报表就必然少一部分数据。
所有时间条件统一用CONVERT_TZ(created_at, '+00:00', '+08:00')显式转换，别依赖 session time_zone 在报表页面加一行小字标注「数据截至北京时间 YYYY-MM-DD HH:MM，含 T-1 日全量」 对关键指标（如付费用户数）单独建校验表，每天比对上游源表和报表宽表的
COUNT(DISTINCT user_id)差值
统计报表真正难的不是写 SQL，而是让每一列数字都有可追溯的源头、可解释的口径、可验证的时效。一旦跳过这些，再漂亮的图表也只是幻觉。
