LAG取上期值必须配ORDER BY，否则按物理顺序取值导致结果错误；时间字段需用DATE_FORMAT归一化为年月，避免断层；同比须先补全时间序列再计算，且分母要用NULLIF防除零。
LAG取上期值必须配ORDER BY，否则结果不可靠
不写ORDER BY时MySQL 8.0虽不报错，但LAG()会按物理存储顺序取值，导致“上月”变成随机行。时间字段必须能严格排序，推荐用DATE_FORMAT(orderdate, '%Y-%m')而非MONTH(orderdate)——后者会让2025-12和2026-01排在一起，破坏时间连续性。
常见错误现象：环比增长率全为NULL或数值明显错乱；排查时先检查SELECT yyyy_mm FROM ... ORDER BY yyyy_mm是否真按年月升序排列。
- 日粒度数据建议先归一化：
DATE_FORMAT(sale_date, '%Y-%m')或YEAR(sale_date)*100 + MONTH(sale_date) - 若存在同月多条记录，
ORDER BY yyyy_mm, sale_id加唯一字段防排序抖动 - 所有
LAG()调用必须共用完全一致的窗口定义，比如都写OVER (ORDER BY yyyy_mm)，不能有的带DESC有的不带
同比用LAG(sales, 12)，但前提是月度数据连续
LAG(sales, 12)不是“找去年同月”，而是“取前12行的值”。如果2025年7月缺失，2026年7月调用LAG(sales, 12)会拿到2025年6月的数据，而非真正的去年同期。
真实业务中，数据断层比想象中更常见。不要依赖LAG(..., 12)自动对齐，而应先补全时间序列（如用CTE + UNION ALL生成完整月份），再做窗口计算。
- 分母为0时必须兜底：
NULLIF(LAG(sales, 12) OVER (...), 0)比CASE WHEN ... = 0 THEN NULL更简洁 - 跨年对比慎用
YEAR(orderdate) - 1拼日期，容易漏掉闰年、月末日期异常等问题 - 若原始表是日粒度，同比计算前务必先按月聚合，否则
LAG(..., 12)可能跳过几十甚至上百行
环比增长率计算要防除零和NULL传播
直接写(sales - LAG(sales)) / LAG(sales)会导致整列变NULL：首行LAG()返回NULL，参与运算后结果全NULL；若某月销售额为0，除法直接失败。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
正确做法是把分母单独处理，且优先用NULLIF()而不是IFNULL()——前者返回NULL可被后续逻辑识别为“不可比”，后者填0反而造成虚假正增长。
- 安全模板：
ROUND((sales - LAG(sales) OVER (...)) * 100.0 / NULLIF(LAG(sales) OVER (...), 0), 2) - 避免重复写
LAG()三次：可在外层查询用别名引用，或用子查询提前算出prev_sales - 增长率结果中首月、断层月天然为
NULL，这是设计使然，不是bug，勿强行用0填充
PARTITION BY漏写会导致跨组串数据
没加PARTITION BY时，LAG()把全表当一个序列处理。比如按产品线分析销售趋势，A产品2026-09的“上月值”可能来自B产品2026-08，完全失真。
分区边界必须与业务维度严格一致。地区、门店、用户ID等高基数字段作PARTITION BY时，注意MySQL 8.0窗口函数在大数据量下内存消耗会上升，必要时加索引加速排序。
- 典型场景必须加：
PARTITION BY product_line ORDER BY yyyy_mm、PARTITION BY region ORDER BY sale_date - 若需同时看全局趋势和分组趋势，可用两个窗口：一个无
PARTITION BY算大盘环比，一个有PARTITION BY算各组环比 -
PARTITION BY字段值含NULL时，这些行会被归入同一组，可能干扰结果，建议提前WHERE partition_col IS NOT NULL
实际中最容易被忽略的是时间字段的归一化和断层处理——窗口函数只认行序，不认业务语义。你给它一堆不连续的月份，它就老老实实跳行取值，不会主动帮你补0或对齐年份。
