MySQL中用YEAR()和MONTH()分组需配合ORDER BY保证时序，且无法走索引；推荐范围查询替代函数过滤，避免DATE_FORMAT()等导致全表扫描。
MySQL 中用 YEAR() 和 MONTH() 直接提取年月分组
如果你的日期字段是 DATETIME 或 DATE 类型，最直白的做法就是用内置函数分别取年和月。但要注意：只用 YEAR(date_col) 和 MONTH(date_col) 两个字段组合分组，会导致 2023-12 和 2024-01 被正确分开，但无法保证结果按时间顺序排列——数据库不保证 GROUP BY 的默认顺序。
实操建议：
- 写法示例：
SELECT YEAR(created_at) AS y, MONTH(created_at) AS m, COUNT(*) FROM orders GROUP BY y, m ORDER BY y DESC, m DESC - 必须加
ORDER BY，否则月份可能乱序（比如 2023-1、2023-12、2023-11 连续出现） -
MONTH()返回的是 1~12 的整数，不是补零格式；如果后续要拼成 "2023-01" 字符串，得用LPAD(MONTH(created_at), 2, '0') - 该方式在有索引的日期字段上，
YEAR()/MONTH()无法走索引下推，大数据量时性能较差
PostgreSQL 里用 EXTRACT() 或 TO_CHAR() 更灵活
PostgreSQL 不支持 YEAR() 这种 MySQL 风格函数，得用标准 SQL 的 EXTRACT()，或者字符串化处理的 TO_CHAR()。后者对前端展示更友好，前者更适合数值计算。
实操建议：
- 按年月数值分组：
SELECT EXTRACT(YEAR FROM order_date) AS y, EXTRACT(MONTH FROM order_date) AS m, COUNT(*) FROM sales GROUP BY y, m - 生成统一格式的年月字符串（如 "2023-01"）：
SELECT TO_CHAR(order_date, 'YYYY-MM') AS ym, COUNT(*) FROM sales GROUP BY ym—— 这种写法可直接用于图表横轴，且天然有序 - 注意：
TO_CHAR()返回文本，若后续要计算同比（比如当前月 vs 上年同月），得再转回日期或拆解字段，不如EXTRACT()直观 - 如果表上有
order_date索引，TO_CHAR(order_date, 'YYYY-MM')无法利用索引；而order_date >= '2023-01-01' AND order_date < '2023-02-01'这种范围查询才能高效走索引
避免用 DATE_FORMAT() 在 WHERE 条件中做年月过滤
常见错误是写成 WHERE DATE_FORMAT(create_time, '%Y-%m') = '2023-01'，这会让整个 create_time 字段上的索引完全失效，全表扫描不可避免。
正确做法永远优先用范围查询：
- 替代上面的慢写法：
WHERE create_time >= '2023-01-01' AND create_time < '2023-02-01' - 如果日期字段允许为
NULL，记得额外加AND create_time IS NOT NULL，避免统计偏差 - 在分组前就缩小数据集，比在海量结果上
GROUP BY快几个数量级；特别是当你要查“最近6个月”时，先WHERE再GROUP BY是底线
需要跨年连续月份统计？别硬拼字符串
比如想看“过去12个月”的月度趋势，要求结果严格按时间倒序（2023-12、2023-11…2023-01），且自动跳过无数据的月份（显示 0）。这时候靠 GROUP BY YEAR+MONTH 本身做不到补零，也不能依赖前端拼接。
实操建议：
- 用递归 CTE（MySQL 8.0+/PostgreSQL）生成完整月份序列，再
LEFT JOIN原表聚合结果 - 简单场景下，可以预建一张只有
ym CHAR(7)字段的“月份维表”，填入未来5年的所有年月，关联更稳定 - 切忌用
CONCAT(YEAR(d), '-', LPAD(MONTH(d),2,'0'))做分组键后排序——字符串排序在 2023-10 和 2023-2 之间会出错（因为 '2023-10' < '2023-2' 字典序成立）
