按天统计活跃用户数时，date()函数默认按服务器时区截取日期，若数据库在utc而业务在东八区，会将北京时间2024-03-01 00:30:00误判为2024-02-29；正确做法是用convert_tz显式转换时区后再取日期。
按天统计活跃用户数时，date() 函数的时区陷阱
MySQL 的 DATE() 函数直接截取 datetime 字段的日期部分，但默认按服务器时区执行——如果你的业务用户集中在东八区，而数据库服务器在 UTC 时区，DATE(created_at) 会把北京时间 2024-03-01 00:30:00 当成 UTC 时间，误判为 2024-02-29。结果就是活跃用户数在每日零点前后出现断层或重复。
正确做法是显式转换时区：
SELECT DATE(CONVERT_TZ(created_at, '+00:00', '+08:00')) AS dt, COUNT(DISTINCT user_id) AS dau FROM events WHERE created_at >= '2024-03-01' AND created_at
- 别依赖系统变量
time_zone，它可能被会话临时修改 - PostgreSQL 用
created_at AT TIME ZONE 'Asia/Shanghai'替代CONVERT_TZ - 如果表里只有 Unix timestamp（秒级整数），先用
FROM_UNIXTIME(ts, '+08:00')转为带时区的时间再取日期
周活跃用户（WAU）不能简单用 WEEK() 函数分组
WEEK(created_at) 默认以周日为起点、且受 default_week_format 影响，不同 MySQL 版本行为不一致；更严重的是，它不区分年份——2023 年最后一周和 2024 年第一周可能返回相同数字，导致跨年 WAU 合并错误。
安全做法是构造「年-周」唯一标识：
SELECT YEARWEEK(created_at, 1) AS yw, COUNT(DISTINCT user_id) AS wau FROM events WHERE created_at >= DATE_SUB(NOW(), INTERVAL 60 DAY) GROUP BY yw;
-
YEARWEEK(..., 1)表示周一为每周起点，ISO 标准（第 1 周包含当年第一个周四） - 过滤条件必须覆盖至少 7 天以上数据，否则某周可能因数据延迟未满 7 天而漏计
- 若需按自然周（周一至周日）对齐报表，用
DATE_SUB(created_at, INTERVAL WEEKDAY(created_at) DAY)计算当周周一日期
月活（MAU）统计中去重逻辑与性能的平衡
直接 COUNT(DISTINCT user_id) 在千万级用户表上容易触发临时磁盘表，尤其当 GROUP BY month 配合大时间范围时。更隐蔽的问题是：如果某用户在 3 月 31 日和 4 月 1 日各有一条记录，他会被同时计入 3 月和 4 月 MAU——这符合定义，但若下游误以为是“连续活跃”，就会产生误导。
优化方向不是避免去重，而是控制计算粒度：
- 用
DATE_FORMAT(created_at, '%Y-%m')替代YEAR(created_at), MONTH(created_at)，减少表达式计算开销 - 加复合索引：
(created_at, user_id)，让 MySQL 能用索引下推快速过滤 + 覆盖扫描 - 对超大表，考虑提前物化每月活跃用户 ID 到汇总表，用
INSERT ... SELECT DISTINCT每日凌晨跑一次，避免每次查询都实时去重
小时级活跃（HAU）要注意事件时间与处理时间偏差
用户点击行为写入数据库存在延迟，尤其在高并发或异步落库场景下，created_at 可能比真实发生时间晚几分钟甚至更久。若按 HOUR(created_at) 统计，凌晨 00:58 的请求被记到 01 点，会导致 HAU 曲线在整点处异常凸起。
解决方案取决于数据链路可控性：
- 如果埋点 SDK 上报时携带了客户端时间戳（如
event_time字段），优先用它做分组：DATE_FORMAT(event_time, '%Y-%m-%d %H:00:00') - 若只有服务端时间，可对延迟建模：查出最近 24 小时内
created_at - event_time的 P95 延迟值（比如 92 秒），然后将统计窗口后移对应秒数 - 绝对不要用
NOW()或CURRENT_TIMESTAMP作为分组依据——它们反映的是 SQL 执行时刻，不是事件发生时刻
时间粒度越细，时钟一致性越关键。DAU 看错一天影响有限，HAU 看错一小时可能直接掩盖真实流量高峰。
