MySQL用QUARTER()函数提取季度并需与YEAR()联合GROUP BY防跨年混淆，NULL值需过滤；PostgreSQL推荐EXTRACT(QUARTER FROM ...)并转int；SQL Server用DATEPART(q, ...)但要注意时区对齐。
MySQL里用QUARTER()提取季度再GROUP BY
MySQL原生支持按季度分组，核心是QUARTER()函数，它把日期转成1~4的整数。注意它只认DATE或DATETIME类型字段，如果字段是字符串（比如'2023-05-12'），MySQL会自动隐式转换；但要是格式不标准（如'2023/05/12'），就得先用STR_TO_DATE()转一遍。
常见写法：
SELECT QUARTER(sale_date) AS quarter, YEAR(sale_date) AS year, SUM(amount) AS total_sales FROM sales GROUP BY YEAR(sale_date), QUARTER(sale_date) ORDER BY year, quarter;
-
GROUP BY必须同时包含YEAR()和QUARTER()，否则2022年Q4和2023年Q4会被混在一起 - 别直接
GROUP BY QUARTER(sale_date)——跨年数据全塌了 - 如果
sale_date允许为NULL，QUARTER(NULL)返回NULL，这行会被单独分组，要提前用WHERE sale_date IS NOT NULL过滤
PostgreSQL怎么写？没有QUARTER()函数
PostgreSQL没内置QUARTER()，得靠EXTRACT()配合MONTH计算：用EXTRACT(MONTH FROM sale_date)拿到月份数，再套公式FLOOR((month - 1) / 3) + 1得到季度。
实操时更推荐直接用EXTRACT(QUARTER FROM sale_date)——PostgreSQL其实支持这个写法，只是文档里藏得深，很多人不知道。
SELECT EXTRACT(YEAR FROM sale_date) AS year, EXTRACT(QUARTER FROM sale_date) AS quarter, SUM(amount) AS total_sales FROM sales GROUP BY year, quarter ORDER BY year, quarter;
-
EXTRACT(QUARTER FROM ...)返回的是double precision类型（比如1.0），排序没问题，但显示看着别扭；可以加::int强转：EXTRACT(QUARTER FROM sale_date)::int - 如果表里有大量历史数据，确保
sale_date字段上有索引，否则EXTRACT()无法走索引，全表扫描很慢
SQL Server的DATEPART(q, ...)要注意时区和首日设置
SQL Server用DATEPART(q, sale_date)取季度，看起来简单，但实际容易踩两个坑：一是DATEPART受DATEFIRST设置影响（虽然对季度没用），二是如果sale_date带时区偏移（比如datetimeoffset类型），得先用SWITCHOFFSET()或TODATETIMEOFFSET()对齐业务时区，否则跨时区汇总可能错乱。
- 季度值是整数，直接
GROUP BY DATEPART(q, sale_date)没问题，但同样要搭配YEAR(sale_date)防跨年 - 如果用
datetime2类型且精度高（如datetime2(7)），DATEPART完全兼容，不用降级处理 - 旧版本SQL Server（2005以前）不支持
DATEPART(q, ...)，得用(MONTH(sale_date) + 2) / 3手动算，现在基本不用考虑了
跨数据库可移植写法：用DATE_FORMAT()或字符串截取（不推荐）
想写一次SQL跑多个数据库？别信“通用方案”。DATE_FORMAT(sale_date, '%Y-Q%q')在MySQL可用，PostgreSQL不认%q，SQL Server压根没DATE_FORMAT。硬用字符串截取（比如SUBSTRING(CAST(sale_date AS VARCHAR), 6, 2)）更危险——月份'01'和'10'截出来都是'01'，季度全乱。
真要兼顾，就老老实实按目标库分别写，或者在应用层做聚合（比如查出明细日期+金额，用Python/Java按date.year和(date.month - 1) // 3 + 1分组）。数据库层强行统一，十次有九次翻车。
季度分组看着简单，但YEAR()和QUARTER()的组合、空值处理、时区对齐、索引有效性，每个点都可能让结果差一倍。别跳过EXPLAIN或EXECUTION PLAN看执行路径——尤其当数据量上百万后，函数包裹字段会让索引失效。
