<p>LAG需配合PARTITION BY user_id ORDER BY login_date才能正确获取用户逻辑前一天登录日期，否则会跨用户或时间错序；务必确保login_date为DATE类型并去重，MySQL用DATEDIFF(login_date, LAG(...))，PostgreSQL用login_date - LAG(...)，NULL值需显式处理。</p>
LAG函数怎么写才能拿到前一天的登录日期
直接用 LAG(login_date) 不行，它默认取上一行，但用户可能隔天登录，必须按用户分组、按日期排序后取“逻辑上的前一天”。关键在 PARTITION BY user_id ORDER BY login_date —— 没这个，LAG会跨用户混拿数据。
常见错误是漏掉 PARTITION BY，导致张三的记录里出现李四的登录日期；或者用 ORDER BY id 代替 login_date，结果时间乱序，差值算错。
实操建议：
- 确保
login_date是DATE类型（不是DATETIME或字符串），否则LAG()虽能执行，但后续日期减法会出隐式转换问题 - 如果表里有重复日期（同一用户单日多次登录），先用
DISTINCT ON (user_id, login_date)或GROUP BY user_id, login_date去重，否则 LAG 可能从同一天内不同记录中取值 - PostgreSQL 和 MySQL 8.0+ 支持标准语法；MySQL 5.7 不支持窗口函数，得用自连接或变量模拟
计算连续天数时，为什么用 DATEDIFF 而不是直接减
因为 LAG(login_date) - login_date 在 PostgreSQL 中返回 interval，而 MySQL 返回整数天数，行为不一致。统一用 DATEDIFF(login_date, LAG(login_date) OVER (...))（MySQL）或 login_date - LAG(login_date) OVER (...)（PostgreSQL）更可控——但注意符号：PostgreSQL 中结果为正表示“今天比昨天晚”，MySQL 的 DATEDIFF(a,b) 是 a 减 b，所以也是正数。
最容易踩的坑是把顺序搞反：DATEDIFF(LAG(...), login_date) 会得到负数，后续判断 = 1 就永远不成立。
实操建议：
- MySQL 用户必须用
DATEDIFF(login_date, LAG(login_date) OVER (...)) - PostgreSQL 用户可用
login_date - LAG(login_date) OVER (...)，结果是整数天数（INTERVAL类型需EXTRACT(DAY FROM ...)） - SQL Server 用
DATEDIFF(day, LAG(login_date) OVER (...), login_date)
如何标记“是否为连续登录的第二天”
不能只看差值是否等于 1，第一天登录的用户没有“前一天”，LAG() 返回 NULL，DATEDIFF 也会是 NULL。必须显式处理 NULL，否则整个条件判断失效。
典型写法是：CASE WHEN LAG(login_date) OVER (...) IS NULL THEN 0 ELSE DATEDIFF(...) END = 1，再套一层 CASE WHEN ... THEN 1 ELSE 0 END 得到标志位。
实操建议：
- 别用
ISNULL()或COALESCE()填充 LAG 结果——填 0 或某个假日期会导致差值异常，比如填 '1970-01-01'，那第一天就变成和 1970 年差几千天，误判为不连续 - 连续登录起始点天然就是
LAG()为 NULL 的行，这是锚点，后续所有连续段都依赖它 - 如果要统计“当前连续多少天”，需要用递归 CTE 或累计计数（如 SUM() OVER + CASE），LAG 本身只解决“是否连着上一天”这一步
性能差？可能是没建好索引
LAG 需要对每个分区做排序，当用户量大、登录记录多时，PARTITION BY user_id ORDER BY login_date 这个组合如果没有索引，就会触发全表排序，慢得明显。
实操建议：
- 在 MySQL/PostgreSQL 中建联合索引：
CREATE INDEX idx_user_login ON login_table (user_id, login_date) - 避免在
login_date上用函数（如DATE(login_time)），否则索引失效，LAG 性能暴跌 - 如果表每天新增百万级记录，考虑按月分区（如
PARTITION BY RANGE (TO_DAYS(login_date))），让 LAG 只扫最近分区
连续登录分析真正难的不是 LAG 语法，而是数据质量：日期字段是否干净、用户标识是否稳定、是否存在时区混用。这些不先理清，函数写得再对也跑不出真实结果。
