JOIN时日期类型不一致会导致索引失效和数据遗漏，应统一用DATE()截取或预聚合；同比需按自然月对齐（如'%Y-%m'），用LAG(...,12) OVER(ORDER BY ym)，并补全缺失月份；环比需校验数据完整性，避免因延迟导致错误。
JOIN时日期字段类型不一致导致关联失败
MySQL或PostgreSQL里用DATE和DATETIME字段直接JOIN，常出现“查不到数据”——不是逻辑错，是隐式转换把索引干掉了。比如orders.order_time是DATETIME，而stats.report_date是DATE，直接ON orders.order_time = stats.report_date会强制把DATETIME转成DATE，索引失效，还可能漏掉当天后半段数据。
实操建议：
- 统一用
DATE()显式截取：ON DATE(orders.order_time) = stats.report_date - 更推荐在JOIN前预处理：把
orders表先按天聚合（GROUP BY DATE(order_time)），再和stats表DATE字段等值JOIN - 避免在JOIN条件里用函数包装被驱动表字段（如
DATE(stats.report_date)），否则无法走索引
窗口函数计算同比（year-over-year）必须用PARTITION BY年月
想算“2024年5月销售额 vs 2023年5月”，不能只靠LAG(value, 12)——月份错位、闰年、春节偏移都会让结果漂移。核心是把时间对齐到“自然月粒度”，而不是简单跳12行。
实操建议：
- 先用
DATE_FORMAT(order_date, '%Y-%m')或TO_CHAR(order_date, 'YYYY-MM')生成ym字段 -
PARTITION BY ym ORDER BY ym没意义，要改成ORDER BY ym，然后LAG(sum_amount, 1) OVER (ORDER BY ym)才能保证是上一月；同比则用LAG(sum_amount, 12) OVER (ORDER BY ym) - 如果数据跨多年但某月缺失（如2023年2月没数据），
LAG(..., 12)会取到2022年2月，必须补全月份：用GENERATE_SERIES（PostgreSQL）或日历表LEFT JOIN再开窗
环比（month-over-month）在月初/月末容易因数据延迟出错
业务系统常在每月1号凌晨才跑完上月结算，若查询执行时间是6月1日00:05，LAG可能拉到空值或旧快照，导致环比显示-100%。这不是SQL写错了，是数据就还没到位。
实操建议：
- 加校验：用
COUNT(*) OVER (PARTITION BY ym)确认当月数据条数是否达到基线阈值（比如≥95%的均值） - 用
COALESCE(LAG(...), 0)掩盖空值只是掩耳盗铃，应配合WHERE ym 主动排除未完结月份 - 生产环境建议把同比/环比逻辑下沉到物化视图或定时ETL任务里，而非每次查询实时算
LEFT JOIN + 窗口函数组合时NULL传播问题
用LEFT JOIN补日期维度后开窗，经常发现LAG结果全为NULL——不是函数不会用，是ORDER BY字段含NULL（比如右表没匹配上的report_date是NULL），导致窗口排序崩了，所有行被归到同一组或乱序。
实操建议：
- 确保
ORDER BY字段非NULL：ORDER BY COALESCE(stats.report_date, '1970-01-01')，但更稳妥的是先FILTER WHERE stats.report_date IS NOT NULL - 别在
SELECT里混用JOIN结果和窗口函数：先WITH base AS (...) SELECT ..., LAG(...) OVER (...) FROM base，避免优化器把JOIN和窗口压进一个执行阶段引发不可控行为 - PostgreSQL中可用
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW显式限定帧，比默认RANGE更可控
日期对齐永远比函数调用难——窗口函数只是工具，真正卡住人的，是业务定义的“同比”到底指自然月、财月，还是滚动30天；这些必须在JOIN前用确定性规则固化，不能指望SQL自动猜。
