LAG() 是最简洁获取前一日用户数的方式，避免自连接缺日错位；需先按 date 去重统计再 LAG；用 NULLIF 防除零；“新增”须基于用户首次行为时间而非简单 GROUP BY；旧版 MySQL 可用 LEFT JOIN 模拟。
用 LAG() 算前一天的用户数，别硬写自连接
直接用 LAG() 获取前一日累计或新增用户数，是最简洁、可读性最强的方式。自连接虽然能实现，但容易漏掉某天无数据的情况（比如中间缺一天），导致错位；而 LAG() 按时间排序后天然对齐，缺失日期会返回 NULL，你一眼就能发现断点。
实操建议：
- 确保分组和排序字段明确：
ORDER BY date是必须的，否则LAG()结果不可控 - 新增用户数需先按
date去重统计（如COUNT(DISTINCT user_id)），再套LAG()，不能对原始行为表直接LAG() - 如果某天没新增用户，
LAG(count)仍会取上一个非空值——除非显式加IGNORE NULLS（仅 Oracle/BigQuery 支持；PostgreSQL 和 MySQL 不支持，得用子查询兜底）
增长率公式里分母为 0 的坑，NULLIF() 比 CASE WHEN 更轻量
当首日新增用户数为 0，或某天突然归零时，直接除会导致除零错误或意外的 INF。很多人习惯写一长串 CASE WHEN count_prev = 0 THEN 0 ELSE (count_curr - count_prev)::float / count_prev END，其实没必要。
更稳妥的做法是：
- 用
NULLIF(count_prev, 0)把分母为 0 的情况转成NULL，让整条表达式自然返回NULL，避免中断执行 - 后续如需展示为 0 或“-”，再统一用
COALESCE(……, 0)或COALESCE(……, '-')处理，职责分离更清晰 - 注意类型：MySQL 中整数除整数默认截断，务必显式转
CAST(…… AS DECIMAL)或乘 1.0；PostgreSQL 可用::numeric
“每日新增”不是 GROUP BY date 就完事，得确认业务定义
很多同学一上来就 GROUP BY DATE(event_time)，结果发现数字对不上——因为“新增用户”本质是“首次出现的用户”，不是当天所有用户。如果用户昨天注册、今天才第一次登录，那他不属于“今日新增”。
关键判断点：
- 先算每个
user_id的首次行为时间（MIN(event_time)），再按该时间归到对应日期，才是真正的“新增日” - 这个过程通常需要子查询或 CTE，不能靠外层
GROUP BY补救 - 如果源表已有
first_login_date字段，优先用它；没有的话，ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time)找首行也比聚合更快（尤其数据量大时）
MySQL 8.0+ 和 PostgreSQL 支持开窗，但旧版 MySQL 得绕路
如果你用的是 MySQL 5.7 或更早版本，LAG() 不可用，强行模拟容易出错。这时候不要硬套窗口逻辑，改用关联子查询更稳：
SELECT cur.date, cur.new_users, (cur.new_users - COALESCE(prev.new_users, 0)) * 1.0 / NULLIF(prev.new_users, 0) AS growth_rate FROM daily_new_users cur LEFT JOIN daily_new_users prev ON cur.date = DATE_ADD(prev.date, INTERVAL 1 DAY);注意点：
-
DATE_ADD(…… INTERVAL 1 DAY)比字符串拼接或ADDDATE更可靠，兼容时区变化 - 必须用
LEFT JOIN，保证当天数据不丢；右表用COALESCE(prev.new_users, 0)防止NULL参与计算 - 这种写法在千万级以下数据表现尚可，但超过五千万行建议建
(date)索引，否则全表扫描太慢
实际跑起来最常卡住的地方，其实是“新增用户”的口径没对齐——上游表是否去重？是否排除测试账号？时间字段有没有被时区转换污染？这些不在 SQL 语法里，但错一点，后面全白算。
