同比计算应通过子查询生成“去年同月”字段再关联，避免直接过滤丢数据；环比须用日期函数自连接而非LAG()以防跨月跳变；需注意分组去重、字段类型一致及索引优化。
子查询里怎么写同比（Year-on-Year）计算
做同比分析，本质上是让当前的数据和去年同期的数据“对上号”。这里最关键的，是确保数据库能准确地实现跨年时间对齐。如果图省事，直接用类似 DATE_SUB(NOW(), INTERVAL 1 YEAR) 这样的条件去过滤，很容易踩坑——比如你想查2024年2月的数据，但2023年2月可能压根没有记录，这样一来，整个2024年2月的数据在查询结果里就直接消失了。
新手常犯的错误有两种：一是写成 WHERE year = YEAR(NOW()) - 1 AND month = MONTH(NOW())，这只能查死板的某一个月份，没法批量处理整张表；二是在 SELECT 里硬套条件，比如 YEAR(date_col) = YEAR(NOW()) - 1，这会导致数据库无法使用索引，查询效率大打折扣。
- 正确的思路是什么？ 应该在子查询里，用
DATE_FORMAT(date_col, '%Y-%m')这样的函数，把日期统一规整到“年月”的粒度，并作为一个明确的字段计算出来。然后，在外层查询中，用这个规整后的字段去做JOIN或LEFT JOIN。 - 如果你的表结构比较特殊，没有日期字段，只有独立的年份（
year_num）和月份（month_num）字段，也别慌。可以用CONCAT(year_num, '-', LPAD(month_num, 2, '0'))手动拼接出一个标准的年月字符串，同样可以用于关联。 - 还有一个容易被忽略的细节：时区。
NOW()函数返回的时间，和表中存储的时间字段，是否在同一个时区？对于跨国业务或分布式系统，建议统一转为UTC时间后再进行比对，否则凌晨时段的数据很容易出现错位。
环比（Month-on-Month）为什么不能只靠LAG()函数
提到环比，很多人第一反应就是窗口函数 LAG()。它写起来确实简洁，但有个致命弱点：它依赖窗口内排序的严格连续性。换句话说，LAG() 找的是“前一条记录”，而不是业务意义上“上一个月”。
想象一个场景：2024年3月的销售数据是0，并且这条记录根本没有录入系统。那么，当你计算2024年4月的环比时，LAG(sales, 1) 会跳过不存在的3月，直接找到2月的数据作为基准。这导致4月的环比实际上是在和2月对比，完全扭曲了业务含义。
所以，在真实的生产环境中，我们需要的是确定性的“前一个月”，而不是碰运气的“前一条记录”。这时，就必须祭出“自连接子查询”这个法宝，通过日期函数明确地构造出时间偏移。
- 推荐的结构如下：
LEFT JOIN t AS prev ON DATE_FORMAT(cur.date_col, '%Y-%m') = DATE_FORMAT(DATE_SUB(cur.date_col, INTERVAL 1 MONTH), '%Y-%m')。通过日期函数减一个月，再格式化对比，能完美处理跨年问题。 - 务必避开这个坑： 不要用
cur.year = prev.year AND cur.month = prev.month + 1这种逻辑。一到年底（12月到次年1月），这个逻辑就断掉了，还得写一堆CASE WHEN来修补，得不偿失。 - 如果数据量很大，担心性能，可以给
DATE_FORMAT(date_col, '%Y-%m')这个表达式创建函数索引（MySQL 8.0及以上版本支持）。或者，更稳妥的做法是，在表里冗余一个ym_str CHAR(7)字段来存储年月字符串，并为其建立普通索引。
自连接子查询怎么避免笛卡尔积和NULL陷阱
当你写出 LEFT JOIN (SELECT ...) AS prev 这样的语句时，两个陷阱已经在暗处等着了。
第一个是“笛卡尔积”陷阱。如果子查询里没有用 GROUP BY 或 DISTINCT 进行去重，很可能会和主表形成一对多的匹配。结果就是主表的行数莫名其妙暴增，聚合结果（比如求和）翻了好几倍，出来的数字完全不可信。
第二个是更隐蔽的“NULL”陷阱。当某个月份完全没有任何数据时，连接过来的 prev 表所有字段自然都是 NULL。很多人会用 IFNULL(prev.sales, 0) 把NULL转为0。但这可能掩盖一个严重问题：这个月份是本来就没有业务发生，还是数据漏录了？直接用0代替，会让分析失真。
- 子查询必须规整： 务必包含完整的分组键，比如按
DATE_FORMAT(date_col, '%Y-%m')分组，并对指标使用SUM(sales)等聚合函数。不要直接SELECT *把原始行都拿出来。 - 连接字段类型必须一致： 检查主表和子查询用于连接的字段。一边是
CHAR(7)，另一边是VARCHAR(7)，在某些数据库版本里可能引发隐式类型转换失败，导致JOIN失效，结果全变成NULL。 - 理解NULL的含义： 遇到同比环比结果是NULL，先别急着处理。应该单独执行一下子查询，看看是不是真的没数据。然后再检查是否是连接条件写错了，提前把数据过滤掉了。搞清楚NULL的来源，比盲目替换更重要。
复杂场景下嵌套子查询的性能临界点在哪
当业务逻辑变得复杂，需要三层甚至更多层子查询嵌套时（比如在计算同比的子查询里，还要嵌套一层计算环比的逻辑），性能问题就会突然冒出来。数据库的查询优化器面对多层“派生表”时，往往会变得笨拙，很可能放弃使用索引，转而进行全表扫描。
经验上看，性能拐点通常出现在这两个地方：一是单次查询需要扫描的行数，超过了表总行数的30%；二是某个子查询返回的中间结果集，行数超过了5000行。一旦触及这些临界点，就别再执着于写一个超级复杂的嵌套SQL了。
- 优先考虑临时表： 使用
CREATE TEMPORARY TABLE先把按年月汇总的中间结果存起来，主查询直接去连接这个临时表。这种方法，通常比反复执行相同的复杂子查询要快上3到5倍。 - 把函数从WHERE里请出去： 像
WHERE YEAR(date_col) = 2023这样的写法，会让索引失效。应该改为date_col >= '2023-01-01' AND date_col < '2024-01-01'，这样才能利用索引加速。 - 过滤条件要下沉： 如果非得用嵌套查询，记住一个原则：把最外层的过滤条件，尽可能早地推到最内层的子查询里去。比如先在内层限定
date_col >= '2023-01-01'，这样每一层传递和处理的数据量就大大减少了。
说到底，真正的难点不在于写出多层嵌套的SQL语句，而在于判断什么时候该“物化”中间结果，以及如何发现那些已经失效却还在硬扛的索引。这些光靠感觉是没用的，必须依赖工具——仔细查看 EXPLAIN 执行计划里的 rows（预估扫描行数）和 type（访问类型）列，那才是调优的可靠依据。
