where子句中嵌套查询需确保子查询返回单值，通过关联字段和时间条件一对一匹配；join方式更优，避免重复执行并提升性能；窗口函数适合滚动同比计算，但需补全时间维度；日期处理应精确对齐季度边界，避免硬编码导致偏差。
WHERE子句里用嵌套查询对比去年同期数据
直接在WHERE里写子查询是最常用也最容易出错的方式。比如想查「2024年Q1销售额高于2023年Q1的门店」，不能只靠GROUP BY和ORDER BY——得让每条2024年的记录，动态拿到对应门店去年同一季度的值。
常见错误是子查询返回多行：Subquery returns more than 1 row。这通常是因为没加WHERE条件限制子查询结果为单值，或者关联字段不唯一（比如门店名重复但ID不同）。
- 子查询必须用
SELECT ... FROM ... WHERE store_id = t.store_id AND year = 2023 AND quarter = t.quarter确保一对一匹配 - 外层表要起别名（如
t），子查询里才能引用t.quarter - 如果某门店2023年Q1无数据，子查询返回
NULL，> NULL结果为UNKNOWN，该行会被过滤掉——这是预期行为，不是bug
SELECT t.store_id, t.sales
FROM sales t
WHERE t.year = 2024 AND t.quarter = 1
AND t.sales > (
SELECT s.sales
FROM sales s
WHERE s.store_id = t.store_id
AND s.year = 2023
AND s.quarter = t.quarter
);
用JOIN替代嵌套查询提升可读性和性能
当需要反复引用去年数据（比如同时比销售额、毛利率、订单量），嵌套查询会重复执行三次。改成LEFT JOIN更直观，也更容易加索引优化。
关键点在于：JOIN条件必须包含时间偏移逻辑，且要处理NULL。很多人忘了ON里不能直接写s.year = t.year - 1——某些数据库（如MySQL 5.7）不支持表达式作为JOIN条件的索引下推，导致全表扫描。
- 推荐先用子查询或CTE预计算「去年对应期」字段，再JOIN，避免运行时计算
-
LEFT JOIN保证2024年有数据的门店不会因去年缺数而丢失；但比较时得显式写AND ly.sales IS NOT NULL，否则> NULL仍失效 - 在
sales(store_id, year, quarter)上建联合索引，比单列索引有效得多
SELECT t.store_id, t.sales AS sales_2024q1, ly.sales AS sales_2023q1 FROM sales t LEFT JOIN sales ly ON ly.store_id = t.store_id AND ly.year = 2023 AND ly.quarter = t.quarter WHERE t.year = 2024 AND t.quarter = 1 AND ly.sales IS NOT NULL AND t.sales > ly.sales;
窗口函数解决同比滚动计算（如连续12个月 vs 去年同月）
如果指标是「过去12个月累计销售额 vs 去年同月前12个月累计」，用嵌套查询会极其臃肿。这时LAG()或LEAD()配合PARTITION BY store_id ORDER BY year, month更合适。
注意LAG(sales, 12)默认按排序顺序取前12行，不保证是“去年同月”——必须确保数据已按year, month严格补全（比如2023-02、2024-02之间不能缺2024-01）。缺月会导致偏移错位。
- 先用
GENERATE_SERIES（PostgreSQL）或递归CTE（SQL Server/MySQL 8.0+）补全时间维度，再JOIN事实表 -
LAG()第三个参数可设默认值，比如LAG(sales, 12, 0)避免NULL干扰计算 - Oracle用户注意：
LAG()在WHERE里不可直接过滤，需包在子查询或CTE中
SELECT store_id, year, month,
SUM(sales) OVER (PARTITION BY store_id ORDER BY year, month ROWS BETWEEN 11 PRECEDING AND CURRENT ROW) AS last_12m,
LAG(SUM(sales) OVER (PARTITION BY store_id ORDER BY year, month ROWS BETWEEN 11 PRECEDING AND CURRENT ROW), 12)
OVER (PARTITION BY store_id ORDER BY year, month) AS last_year_12m
FROM sales
GROUP BY store_id, year, month;
日期函数陷阱：跨年季度对齐别硬写数字
用YEAR(date_col) = YEAR(CURDATE()) - 1看似简洁，但遇到季度时容易错——比如当前是2024-04-01（Q2），YEAR()-1得到2023，但Q2对应的是2023-04~2023-06，不是整个2023年。
更危险的是用DATE_SUB(CURDATE(), INTERVAL 1 YEAR)算“去年同期”，它只偏移日期，不考虑季度边界。2024-01-01减1年是2023-01-01，但Q1实际应从2023-01-01到2023-03-31，这个函数本身不定义季度范围。
- 明确用
QUARTER()和YEAR()组合判断，比如QUARTER(date_col) = QUARTER(NOW()) AND YEAR(date_col) = YEAR(NOW()) - 1 - PostgreSQL可用
date_trunc('quarter', now()) - INTERVAL '1 quarter'精准获取上季度起点 - SQL Server建议用
DATEFROMPARTS(YEAR(GETDATE())-1, (DATEPART(QUARTER, GETDATE())-1)*3+1, 1)构造季度首日
复杂点往往不在语法，而在业务定义是否清晰：你比的到底是“自然年同期”“财年同期”，还是“滚动12个月”？一旦定义模糊，所有嵌套逻辑都会偏离目标。
