最可靠路径是用GROUP BY+YEAR()按客户和年份分组聚合；需确保日期字段为DATE/DATETIME类型，字符串类型可能导致SQL Server报错；应先确认字段类型，避免在WHERE中对函数结果过滤而使索引失效。
用 GROUP BY + YEAR() 提取年份并分组聚合
直接对订单日期取年份，再按客户和年份分组，是计算年度销售总额最基础也最可靠的路径。MySQL 的 YEAR()、PostgreSQL 的 EXTRACT(YEAR FROM ...)、SQL Server 的 YEAR(...) 都能完成这件事，但行为一致的前提是日期字段类型为 DATE 或 DATETIME。如果字段是字符串（比如 '2023-05-12'），部分数据库会隐式转换，但 SQL Server 可能报错 Conversion failed when converting date and/or time from character string，务必先确认字段类型。
实操建议：
- 先运行
SELECT typeof(order_date), pg_typeof(order_date) OR type_name(column_id)（依数据库查类型）确认日期列真实类型 - 避免在 WHERE 中对函数结果过滤年份（如
WHERE YEAR(order_date) = 2023），这会让索引失效；改用范围查询：WHERE order_date >= '2023-01-01' AND order_date - 聚合时用
SUM(amount)，别漏掉COALESCE(SUM(amount), 0)——空值会导致整行消失，而不是显示 0
用窗口函数实现跨年对比（如同比、环比）
单纯算出每年总额还不够，多数业务需要“2023 年比 2022 年增长多少”。这时不能靠 JOIN 多次查表，而应优先用窗口函数 LAG() 或 LEAD() 拉取相邻年份数据。它天然保持客户+年份粒度，且不膨胀行数。
注意点：
-
LAG(sum_amount, 1) OVER (PARTITION BY customer_id ORDER BY year)中的ORDER BY year必须严格升序，否则对比错位 - PostgreSQL 和 SQL Server 支持
LAG(..., 1, 0)设置默认值，但 MySQL 8.0+ 才支持第三个参数，旧版需套一层COALESCE(LAG(...), 0) - 若某客户缺失某年数据（比如 2022 年无订单），
LAG会返回 NULL，不是 0 —— 这是合理行为，不代表计算错误
处理跨年客户流失/新增：用年份全集 LEFT JOIN 补零
当需要展示“所有客户在 2021–2023 每年的销售额”，哪怕某客户某年没订单也要显示 0，就不能只查有订单的年份。必须构造一个完整的年份维度表，再与客户维度交叉，最后 LEFT JOIN 实际订单汇总结果。
常见做法：
- 用递归 CTE（PostgreSQL/SQL Server）或
UNION ALL手动拼出年份列表：SELECT 2021 AS year UNION ALL SELECT 2022 UNION ALL SELECT 2023 - 客户列表从
SELECT DISTINCT customer_id FROM orders获取，不要用用户主表——可能包含从未下单的客户，偏离业务口径 - LEFT JOIN 时 ON 条件必须包含
customer_id和year两字段，缺一不可，否则补零失败
性能陷阱：避免在 GROUP BY 中嵌套复杂表达式
有人会写 GROUP BY customer_id, YEAR(order_date)，看起来没问题，但在大数据量下，数据库可能无法复用 order_date 上的索引。更稳妥的是提前算好年份字段——要么在应用层生成 order_year 列并建索引，要么在视图里固化 YEAR(order_date) AS order_year。
尤其要注意：
- MySQL 5.7 不支持函数索引，但 8.0+ 可建
CREATE INDEX idx_orders_year ON orders (customer_id, (YEAR(order_date))) - SQL Server 对
YEAR(order_date)字段建索引无效，必须用计算列：ALTER TABLE orders ADD order_year AS YEAR(order_date) PERSISTED，再对order_year建索引 - 如果报表固定只看最近三年，WHERE 先过滤日期范围，再 GROUP BY，比全表扫描后截取快得多
实际跑起来才发现，年份边界判断（比如把 2023-12-31 23:59:59 当作 2023 还是 2024）、时区影响（UTC 存储 vs 本地时间展示）、以及客户名称变更导致的 ID 不一致——这些细节不会出现在 SQL 语法书里，但每一条都足以让对比结果偏差 20% 以上。
