CEIL(MONTH(date_col)/3.0)可计算季度数1–4，但跨年分组会混淆不同年份的相同季度；必须结合YEAR()使用，推荐MySQL 8.0+用YEAR()和QUARTER()，旧版用FLOOR((MONTH-1)/3)+1。
直接说结论：用 CEIL(MONTH(date_col)/3.0) 确实能算出季度数（1–4），但实际分组时必须配合年份，否则跨年数据会混在一起；更稳妥的做法是用 YEAR(date_col) 和 QUARTER(date_col)（MySQL 8.0+）或 FLOOR((MONTH(date_col)-1)/3)+1（兼容旧版）。
为什么 CEIL(MONTH/3) 在跨年场景下会出错
假设你有一张含 transaction_date 的财务表，执行：SELECT CEIL(MONTH(transaction_date)/3) AS qtr, SUM(amount) FROM sales GROUP BY qtr;
——这会让 2023-12-15（MONTH=12 → CEIL(12/3)=4）和 2024-03-10（MONTH=3 → CEIL(3/3)=1）都映射到“1”或“4”，但它们属于不同自然季度。分组丢失年份维度，结果完全不可信。
常见错误现象：
• 每年Q1收入突然比Q4高一倍（实际是把上一年Q4和本年Q1全加进去了）
• 查询2024年数据却出现2023年Q3的汇总值
- 根本原因：季度是“年+季”的二维概念，单靠月份数学运算无法还原年边界
-
CEIL(MONTH/3)只适合做单年内的逻辑演示，不能用于真实财务口径 - 财务系统要求季度必须对应 ISO 或自然年周期（如 2024-Q1 = 2024-01-01 至 2024-03-31）
MySQL 中推荐的季度分组写法（含版本兼容）
MySQL 8.0+ 直接用内置函数最安全：SELECT YEAR(transaction_date) AS y, QUARTER(transaction_date) AS q, SUM(amount) FROM sales GROUP BY y, q ORDER BY y, q;
MySQL 5.7 或更低版本需手动构造季度标识：SELECT YEAR(transaction_date) AS y, FLOOR((MONTH(transaction_date)-1)/3)+1 AS q, SUM(amount) FROM sales GROUP BY y, q ORDER BY y, q;
-
FLOOR((MONTH-1)/3)+1和CEIL(MONTH/3)数学等价，但显式写出年份避免歧义 - 不要用
CONCAT(YEAR(...), '-Q', QUARTER(...))做分组键——字符串排序可能错乱（如 “2023-Q10” 会排在 “2023-Q2” 前） - 如果要按“2024-Q1”格式展示，放到
SELECT列里用CONCAT，别放进GROUP BY
PostgreSQL / SQL Server 用户注意语法差异
PostgreSQL 不支持 QUARTER() 函数，得用：EXTRACT(YEAR FROM transaction_date) AS y, EXTRACT(QUARTER FROM transaction_date) AS q
SQL Server 推荐：YEAR(transaction_date) AS y, DATEPART(QUARTER, transaction_date) AS q
- 所有数据库中，
DATEPART/EXTRACT/QUARTER()都自动绑定年份，无需额外处理 - 避免手写
CEIL(DATE_PART('month', ...)/3.0)—— PostgreSQL 里DATE_PART返回整数，/3是整除（2024-02 返回CEIL(2/3)=1，但 2024-03 也返回CEIL(3/3)=1，没问题；可一旦写成/3而非/3.0，在某些版本里可能截断为 0） - Oracle 用户请用
TO_CHAR(transaction_date, 'YYYY-Q')，但注意它返回字符串，分组可用，排序需小心
真正容易被忽略的点：财务报表常要求“截至某季度末的累计值”，这时不能只靠 GROUP BY，得加窗口函数或子查询；而 CEIL(MONTH/3) 这类纯数值技巧，在需要滚动累计、同比计算时几乎无法复用——它没携带时间序信息，也没对齐日历边界。
