GDP季度核算以生产法为基础，采用法人单位为核算单位，按国民经济行业分类计算增加值并汇总；核算范围涵盖常住单位在境内所有生产活动，不含港澳台数据。
用 TO_CHAR 提取季度最直观，但要注意年份绑定
直接用 TO_CHAR(order_date, 'YYYY-Q') 能得到类似 '2024-1' 这样的字符串，既带年份又带季度，避免跨年混淆。如果只用 'Q'，所有 Q1 都会混在一起，2023-Q1 和 2024-Q1 就没法区分。
常见错误是写成 GROUP BY TO_CHAR(order_date, 'Q') —— 这会导致不同年份的同一季度被合并统计，结果完全失真。
实操建议：
- 始终把年份和季度一起提取：
TO_CHAR(order_date, 'YYYY-Q') - 若需数值型季度（如 20241 表示 2024 年 Q1），可用
TO_CHAR(order_date, 'YYYY') || TO_CHAR(order_date, 'Q')（Oracle/PostgreSQL）或CONCAT(YEAR(order_date), QUARTER(order_date))（MySQL） - 注意
TO_CHAR行为因数据库而异：Oracle 默认 Q1 是 1–3 月；PostgreSQL 需要EXTRACT(QUARTER FROM order_date)配合EXTRACT(YEAR FROM order_date)才稳妥
CEIL 算季度要小心月份偏移
CEIL(MONTH(order_date) / 3.0) 看似简洁，但容易出错——比如 MONTH('2024-03-15') 是 3，3 / 3.0 = 1.0，CEIL(1.0) = 1，没问题；但 MONTH('2024-01-01') 是 1，1 / 3.0 ≈ 0.333，CEIL(0.333) = 1，也对。表面看没问题，实际隐患在边界处理和可读性上。
问题在于：这个表达式没显式关联年份，必须手动拼接年份字段，否则 GROUP BY 时仍会跨年聚合；而且除法 + CEIL 在某些数据库（如旧版 SQL Server）里可能因整数除法截断导致结果错误（例如 3/3 得 1，但 1/3 得 0）。
实操建议：
- 优先用
CEIL(MONTH(order_date) * 1.0 / 3)强制浮点运算，避免整数除法陷阱 - 必须配合年份：
CONCAT(YEAR(order_date), '-', CEIL(MONTH(order_date) * 1.0 / 3)) - MySQL 中
QUARTER(order_date)更安全，没必要硬套CEIL
按自然季度分组时，WHERE 条件别漏掉时间范围
即使 GROUP BY 写对了，如果没加 WHERE order_date >= '2024-01-01' AND order_date ，历史数据全进来，不仅慢，还可能拉偏季度占比。
尤其当订单表很大、且有多年数据时，没过滤就直接 GROUP BY TO_CHAR(order_date, 'YYYY-Q')，数据库大概率全表扫描，执行时间从毫秒级跳到秒级甚至更久。
实操建议：
- 先用
WHERE锁定业务关心的时间窗，再分组 - 日期条件尽量用左闭右开：
order_date >= '2024-01-01' AND order_date ，比 <code>BETWEEN更可靠（避免时分秒引发的边界遗漏） - 如果要动态取最近 4 个季度，用
DATE_SUB(CURDATE(), INTERVAL 1 YEAR)（MySQL）或ADD_MONTHS(SYSDATE, -12)（Oracle）生成起始时间
不同数据库对季度函数的支持差异大
MySQL 有原生 QUARTER() 和 YEAR()，但不支持 TO_CHAR；Oracle 支持 TO_CHAR 和 CEIL，但 EXTRACT 不常用；PostgreSQL 没 TO_CHAR(..., 'Q')，得靠 EXTRACT(QUARTER FROM ...) 和 EXTRACT(YEAR FROM ...) 拼接；SQL Server 用 DATEPART(quarter, ...)。
这意味着写一次 SQL 想通吃所有数据库几乎不可能。最易踩的坑是照着 Oracle 文档写 TO_CHAR(order_date, 'YYYY-Q') 丢进 MySQL，直接报错 FUNCTION TO_CHAR does not exist。
实操建议：
- 上线前务必在目标数据库验证函数是否存在、行为是否一致
- 如果项目需多库兼容，建议封装成视图或应用层计算季度标识，SQL 层只做简单分组
- 测试时至少覆盖 12 月、1 月、3 月、4 月这四个关键月份，确认 Q4 和 Q1 不跨年错位
季度统计真正麻烦的不是怎么算 Q1/Q2，而是年份和季度必须绑定、时间范围必须收紧、数据库差异必须提前兜底——漏掉任意一点，数据就 quietly 错了。
