用year()与group by按年聚合销售数据最直接，但需确保order_date为date/datetime类型、排除null值，并按业务语义选择正确日期字段；跨数据库需适配函数，同比分析应先聚合再计算。
用 YEAR() 和 GROUP BY 按年聚合销售数据最直接
想快速出年度销售统计，核心就是把日期字段“掰成年份”，再按年分组汇总。MySQL 里最省事的是 YEAR() 函数，它直接从 DATE、DATETIME 字段里抽年份数字，和 GROUP BY 配合毫无歧义。
常见错误是写成 GROUP BY SUBSTRING(order_date, 1, 4) 或手动拼字符串——这不仅慢，还可能因格式不统一（比如 '2023-01-01' vs '01/01/2023'）导致分组错乱。
-
order_date字段必须是DATE或DATETIME类型，否则YEAR()返回NULL - 如果用的是 PostgreSQL，得换成
EXTRACT(YEAR FROM order_date)，不能硬套YEAR() - SQL Server 用户注意：
YEAR(order_date)可用，但若字段含时区信息（如DATETIMEOFFSET），需先用SWITCHOFFSET或CONVERT归一化
SELECT YEAR(order_date) AS year, SUM(amount) AS total_sales FROM sales WHERE order_date >= '2020-01-01' GROUP BY YEAR(order_date) ORDER BY year;
避免跨年订单被重复或漏算：用 DATE_FORMAT() 控制统计口径
销售统计常要区分“订单年”和“发货年”或“开票年”。如果业务规则是按开票日期算年度业绩，但表里只有 order_date，硬用它会失真。这时候不能只依赖函数，得先确认字段语义。
另一个坑是：有些系统存的是字符串日期（如 order_date VARCHAR(10)），看着像 '2023-12-31'，但 YEAR() 对它返回 NULL —— MySQL 会静默转失败，不报错，结果少了一整年的数据。
- 用
SELECT order_date, YEAR(order_date) FROM sales LIMIT 5先验证字段是否真能被识别为日期 - 若字段是字符串且格式统一，可用
STR_TO_DATE(order_date, '%Y-%m-%d')转后再取年份，但性能较差，别在大表上直接用 - 真正稳妥的做法是在 ETL 或插入时就存规范的
DATE类型，而不是现场补救
需要同比/环比？别在 GROUP BY 里硬凑，先用子查询打平结构
年度报告如果要加“上年销售额”“同比增长率”，很多人试图在同一个 GROUP BY 查询里用窗口函数或自连接，结果要么逻辑错，要么性能崩。根本原因是：聚合后的结果集已丢失原始行粒度，没法安全地做跨年计算。
正确做法是把年度聚合结果当临时表，再用 LEFT JOIN 或窗口函数处理。MySQL 8.0+ 支持 LAG()，但要注意排序必须明确，否则 LAG(total_sales) 可能拉错年份。
- 确保
ORDER BY year在窗口函数中显式写出，不能依赖GROUP BY顺序 - 如果数据库版本低于 8.0，用自连接更稳：
JOIN yearly t2 ON t1.year = t2.year + 1 - 空值陷阱：2020 年没数据时，2021 年的
LAG()会是NULL，除法前必须COALESCE(t2.total_sales, 0)
SELECT year, total_sales, LAG(total_sales) OVER (ORDER BY year) AS last_year_sales, ROUND((total_sales - LAG(total_sales) OVER (ORDER BY year)) / NULLIF(LAG(total_sales) OVER (ORDER BY year), 0), 4) AS yoy_rate FROM ( SELECT YEAR(order_date) AS year, SUM(amount) AS total_sales FROM sales GROUP BY YEAR(order_date) ) AS yearly;
导出报表前务必加 WHERE order_date IS NOT NULL
看起来很傻的条件，却是线上事故高发点。销售表里常有测试单、草稿单、迁移残留数据，order_date 为 NULL 或 '0000-00-00'。这些记录经 YEAR() 处理后变成 0 或 NULL，GROUP BY 会把它们全塞进同一组，有时占总量 5% 以上，而且无法从业务上解释。
更隐蔽的是：某些 ORM 自动生成的 SQL 会悄悄忽略 NULL 过滤，或者前端传参时没校验日期字段是否为空字符串，后端又没做转换，最终让脏数据流入聚合。
- 永远在聚合查询开头加
WHERE order_date >= '2010-01-01' AND order_date IS NOT NULL（下限按实际业务定） - 检查
SHOW CREATE TABLE sales，确认order_date是否有NOT NULL约束，没有就补上 - 如果历史数据已污染，用
UPDATE sales SET order_date = NULL WHERE order_date = '0000-00-00'清洗，别留侥幸心理
日期函数和 GROUP BY 的组合本身不难，难的是每一步都得对齐业务定义、数据质量、数据库版本这三个变量。少盯一个，报告就可能在财务对账时卡住。
