MySQL中YEAR()和MONTH()单独分组会导致跨年同月数据合并，正确做法是用DATE_FORMAT(created_at,'%Y-%m')或YEAR()*100+MONTH()构造唯一年月标识；PostgreSQL应使用TO_CHAR(created_at,'YYYY-MM')或DATE_TRUNC('month',created_at)；SQL Server推荐CONVERT(char(7),created_at,126)替代低效FORMAT()；补全缺失月份需生成连续年月序列后LEFT JOIN。
MySQL中用YEAR()和MONTH()分组年月时为什么结果不对？
直接套用 YEAR(created_at) 和 MONTH(created_at) 两个字段分组，看似合理，但会把2023年1月和2024年1月归到同一组（因为MONTH()只返回1~12），实际是按“纯月份”而非“年月组合”分组。真正要的是带年份的月粒度，比如“2023-01”、“2023-02”。
正确做法是构造唯一年月标识：
- 推荐用
DATE_FORMAT(created_at, '%Y-%m')—— 输出字符串如'2023-01'，直观、可排序、易读 - 也可用
YEAR(created_at) * 100 + MONTH(created_at)—— 输出整数如202301，适合做数值计算或索引优化，但不可读 - 避免单独
GROUP BY YEAR(), MONTH()，除非你明确需要跨年聚合同月数据（极少见）
PostgreSQL里没有DATE_FORMAT，怎么安全提取年月？
PostgreSQL不支持DATE_FORMAT，但有更严谨的日期类型处理方式。别用字符串拼接（如 EXTRACT(YEAR FROM date)::text || '-' || EXTRACT(MONTH FROM date)::text），它会导致'2023-1'这种不等宽格式，排序和比较出错。
必须保证月份始终两位数：
- 用
TO_CHAR(created_at, 'YYYY-MM')—— 最简洁，输出'2023-01'，行为与MySQL的DATE_FORMAT一致 - 或用
DATE_TRUNC('month', created_at)—— 返回时间类型值如'2023-01-01 00:00:00'，适合后续时间运算，但分组后显示不够干净 - 注意：
EXTRACT(YEAR FROM ...)和EXTRACT(MONTH FROM ...)是独立函数，不能直接在GROUP BY里合用实现年月唯一分组，仍需组合或格式化
SQL Server中FORMAT()性能差，有没有更高效替代方案？
FORMAT(created_at, 'yyyy-MM')写起来顺手，但底层调用.NET，对大表分组会造成明显性能下降，尤其在WHERE或JOIN中嵌套使用时。
生产环境建议改用确定性表达式：
- 用
CONVERT(char(7), created_at, 126)—— 返回'2023-01'（126格式默认含年月日，截取前7位即可） - 或
YEAR(created_at) * 100 + MONTH(created_at)，再配合CAST(... AS char(6))转字符串（需补零：用RIGHT('000000' + CAST(... AS varchar), 6)） - 如果表上有大量查询按年月过滤，建议在表中增加计算列
year_month AS (CONVERT(char(7), created_at, 126)) PERSISTED并建索引，比每次运行时计算快得多
按年月分组后如何补全缺失月份（比如2023年缺3月数据）？
原始数据天然稀疏，分组后只会返回有记录的年月。要强制展示所有目标区间内的年月（如2023全年12个月），必须生成完整时间序列再LEFT JOIN。
不同数据库生成方式不同，但核心逻辑一致：
- MySQL 8.0+：用
WITH RECURSIVE months AS (...)递归生成日期序列 - PostgreSQL：用
GENERATE_SERIES('2023-01-01'::date, '2023-12-01'::date, '1 month') - SQL Server：用
master..spt_values（不推荐）或CTE +ROW_NUMBER()构造数字序列，再转为日期 - 关键点：生成的序列字段必须和主表分组字段类型、格式完全一致（比如都用
'YYYY-MM'字符串），否则LEFT JOIN无法匹配
补全逻辑本身不难，难在跨数据库语法差异大，且容易忽略类型对齐——字符串'2023-1'和'2023-01'在JOIN时就是不相等的。
