GROUP BY 不支持变量，需用 CASE 或日期函数构造逻辑维度列；推荐 UNION ALL 拆分多粒度查询以保障索引与可维护性；窗口函数须在最小粒度聚合后使用，并注意时区、月末、夏令时等边界问题。
GROUP BY 里不能直接用变量，但可以用 CASE + 表达式模拟动态维度
SQL 标准不支持把列名或分组字段当作变量传入 GROUP BY，比如写成 GROUP BY @time_dim 会报错。真正可行的路径是：把多个时间维度（年、月、周、日）预先用 CASE 或日期函数展开为计算列，再在 GROUP BY 中引用这些列。
常见错误是试图拼接 SQL 字符串（尤其在应用层做字符串替换），这容易引发注入、类型不一致、时区错乱等问题。更稳的方式是在 SQL 内部用逻辑判断收敛到统一结构。
-
YEAR(order_time)、DATE_FORMAT(order_time, '%Y-%m')（MySQL）、EXTRACT(YEAR FROM order_time)（PostgreSQL）这类函数可提取固定粒度，但无法“切换” - 若需同一份 SQL 支持多种粒度，推荐定义一个“逻辑时间维度列”，例如：
CASE WHEN @dim = 'year' THEN YEAR(order_time) WHEN @dim = 'month' THEN YEAR(order_time) * 100 + MONTH(order_time) WHEN @dim = 'week' THEN YEARWEEK(order_time, 1) ELSE DATE(order_time) END AS time_key
- 注意：不同数据库对
YEARWEEK、DATE_TRUNC的周起始日（周日 vs 周一）、时区处理不一致，生产环境务必显式指定参数，如YEARWEEK(order_time, 1)中的1表示周一为每周起点
用 UNION ALL 拆分查询比条件分支更易维护和优化
当多维度报表需要各自独立的聚合逻辑（比如周维度要算周一到周日、月维度要对齐自然月），硬塞进一个 CASE 容易让 SQL 膨胀且难调试。这时不如按维度拆成多个子查询，用 UNION ALL 合并结果，每块只专注一种时间切片逻辑。
好处是执行计划清晰、索引能被有效利用（例如对 order_time 建了 B-tree 索引，WHERE order_time >= '2024-01-01' 在月维度查询中可走索引，而混合 CASE 可能导致全表扫描）。
- 每个子查询必须保持列名、数据类型一致，否则
UNION ALL会失败；建议统一用CAST显式转类型，例如：CAST(YEAR(order_time) AS CHAR(4)) AS time_label - 避免在
UNION ALL外层再套复杂ORDER BY或LIMIT，优先让每个子查询内部完成排序和截断 - 如果只查其中一种维度，直接注释掉其余
SELECT ... UNION ALL块即可，比开关CASE条件更直观
窗口函数配合 GROUP BY 实现“带同比/环比的动态分组”
单纯分组汇总只是第一步；实际报表常需在同一行显示“本月销售额”和“上月销售额”。这时不能只靠 GROUP BY，得引入窗口函数提前拉出相邻周期的数据。
关键点在于：先按最小时间粒度（如日）聚合，再用窗口函数跨行取值，最后按目标维度（如月）二次聚合。强行在月粒度上直接用 LAG(SUM(amount), 1) OVER (ORDER BY month) 是错的——因为 SUM 已经折叠了行，LAG 无行可跨。
- 正确顺序：
-- Step1：按天聚合 WITH daily AS ( SELECT DATE(order_time) AS dt, SUM(amount) AS amt FROM orders GROUP BY DATE(order_time) ), -- Step2：加窗口字段（前一日、前7日、前30日） with_lag AS ( SELECT *, LAG(amt, 1) OVER (ORDER BY dt) AS prev_day, AVG(amt) OVER (ORDER BY dt ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS avg_7d FROM daily ), -- Step3：按月再 GROUP BY，并引用窗口结果 monthly AS ( SELECT YEAR(dt) AS y, MONTH(dt) AS m, SUM(amt) AS month_total, SUM(prev_day) AS last_month_total -- 注意：这里 sum(prev_day) 是近似，真实场景应按月对齐而非简单求和 FROM with_lag GROUP BY YEAR(dt), MONTH(dt) ) - 注意：
LAG和LEAD默认按ORDER BY排序后取物理行，不是按业务时间对齐。如果某天缺数据，LAG会跳到更早一天，而非“上一个自然日”。补数或用GENERATE_SERIES（PostgreSQL）/递归 CTE（MySQL 8.0+）生成完整时间轴更可靠
时区、夏令时、月末边界是高频翻车点
所有时间维度计算都隐含时区假设。如果数据库服务器时区是 UTC，而业务要求按北京时间（UTC+8）统计，直接用 DATE(order_time) 会把 00:00–07:59 的订单错划到前一天。
更隐蔽的是夏令时切换日（如美国每年3月第二个周日），TIMESTAMP 类型可能重复或跳过一小时，导致 GROUP BY HOUR() 出现空桶或双倍计数。
- 强制统一时区：在查询开头用
CONVERT_TZ(order_time, '+00:00', '+08:00')（MySQL）或order_time AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai'（PostgreSQL）转换后再提取维度 - 月末逻辑别信
LAST_DAY()返回值直接参与比较；它返回的是该月最后一天的日期，但如果你的字段是DATETIME，且想查“3月1日至3月31日23:59:59”，得写成order_time <= LAST_DAY('2024-03-01') + INTERVAL 1 DAY，否则漏掉最后一秒 - 测试时至少覆盖两个时区交界日（如 UTC 时间 2024-03-10 09:59 和 10:01），看是否出现单条记录被分到两个分组里
实际写的时候，最麻烦的往往不是语法，而是确认“这个‘月’到底指自然月、财月，还是滚动30天”，以及“用户点击‘周’时，期望看到的是本周一到今天，还是完整周一到周日”。这些业务规则必须在 SQL 层显式编码，没法靠通用模板自动适配。
