MySQL 8.0.13+才稳定支持LAG/LEAD，需确认VERSION()≥8.0.13、optimizer_switch含window_functions=on，且OVER()必须带ORDER BY；精准取某行相邻记录须先排序再定位行号，不可直接WHERE筛选后开窗。
MySQL 8.0+ 才能直接用 LAG 和 LEAD 获取相邻行，低于这个版本会报错 FUNCTION xxx does not exist 或提示语法错误 —— 别白费劲去查兼容写法，真要支持旧版，只能靠自连接或变量模拟，但逻辑复杂、性能差、边界易出错。
确认 MySQL 版本并启用窗口函数
执行 SELECT VERSION();，输出必须 ≥ 8.0.0。部分云厂商（如早期阿里云 RDS）默认禁用窗口函数，需检查配置项：optimizer_switch 中是否包含 window_functions=on。若不可改，换实例或升级内核。
- 常见误判：看到
8.0.x就以为可用，实际某些8.0.11之前的子版本存在窗口函数解析 bug，建议最低使用8.0.13及以上 -
OVER()必须带ORDER BY，否则报错You have an error in your SQL syntax；PARTITION BY是可选的，但漏写可能导致跨业务数据混算
用 LAG/LEAD 提取“某条记录”的前后行，不是整列偏移
很多人以为 LAG(col, 1) 就能拿到“目标 ID 那一行的上一条”，其实不是——它对**整个结果集按 ORDER BY 排序后逐行计算**。想精准定位某条记录的邻居，得先筛选再套窗口，或用子查询嵌套。
- 错误写法：
SELECT *, LAG(id) OVER (ORDER BY create_time) AS prev_id FROM logs WHERE id = 123;→ 这里WHERE在窗口计算之后执行，LAG算的是全表排序后的前一行，不是id=123那行的前一条 - 正确思路：先用子查询/CTE 拿到目标行及其排序位置，再用
ROW_NUMBER()定位前后行号，最后 JOIN 回原表。例如：WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (ORDER BY create_time) AS rn FROM logs ) SELECT curr.*, prev.*, next.* FROM ranked curr LEFT JOIN ranked prev ON prev.rn = curr.rn - 1 LEFT JOIN ranked next ON next.rn = curr.rn + 1 WHERE curr.id = 123;
- 如果只关心时间相邻（比如打卡记录），直接
LEAD(create_time) OVER (ORDER BY create_time)算间隔更稳，不用强求“ID 相邻”
LEAD/LAG 的 default 参数不填时返回 NULL，别假设它自动跳过
LAG(col, 1) 在第一行永远返回 NULL，LEAD(col, 1) 在最后一行也返回 NULL。如果后续要做减法或除法（比如计算时间差），没处理 NULL 会导致整列结果为 NULL。
- 数值差值场景：用
LAG(col, 1, 0)填 0，但注意 0 可能和真实值混淆；更安全是显式判断：COALESCE(LAG(col) OVER (...), col) - 日期差值场景：用
LEAD(create_time, 1, '9999-12-31') OVER (...)避免TIMESTAMPDIFF报错，但要注意这个兜底时间可能影响业务逻辑 - 字符串场景：
LAG(name, 1, '(无前序)')比NULL更易读，尤其在报表导出时
真正难的不是写对 LAG 或 LEAD，而是想清楚“相邻”到底指什么：是主键顺序？时间戳顺序？还是业务状态变更顺序？一旦排序依据和业务语义错位，结果就完全不可信。比如按 create_time 排序查订单前后单，但同一秒插入多条，就得加二级排序（如 ORDER BY create_time, id）来保证确定性。
