跨年业绩对比是SQL应用中的高频场景，但真上手做的时候就会发现，往往是看似不起眼的小问题导致结果全军覆没。来看几个最翻车的现象，以及每一步该怎么兜底。

JOIN时年份字段类型不一致导致结果为空

先说最常见的情况：一张表用INT存年份，比如2023；另一张表用CHAR(4)或者干脆是个DATE类型（比如'2023-01-01'）。LEFT JOIN做完一看，本该有数据的地方全成NULL了。数据库不会自动去提取年份里的那四位数字来匹配，匹配直接失败。

那怎么救？

• 统一用YEAR()函数提取年份：比如YEAR(sales_date)和year_col比较，这样就不依赖字段原始类型了。

• 用显式转换：一方是字符串，就用CAST(year_str AS SIGNED)（MySQL）或者TO_NUMBER(year_str)（PostgreSQL）转为数值再去比对。

• 跑完EXPLAIN看一下type是不是ALL——如果是，说明压根没走索引，大概率就是类型不匹配把索引弄失效了。

用FULL OUTER JOIN模拟跨年对比（但MySQL不支持）

现在想做个更全面的对比：哪些客户2022年有业绩但2023年没动静，哪些是2023年新冒出来的客户。这种需求本来该用FULL OUTER JOIN，但MySQL一直到8.0.29都不原生支持，硬写就会遇到ERROR 1064。

怎么办？组合拳走起来：

• 用UNION ALL + LEFT JOIN + RIGHT JOIN来模拟：
  

  SELECT a.customer_id, a.sales_2022, b.sales_2023
  FROM t_2022 a
  LEFT JOIN t_2023 b ON a.customer_id = b.customer_id
  UNION ALL
  SELECT b.customer_id, NULL, b.sales_2023
  FROM t_2023 b
  LEFT JOIN t_2022 a ON a.customer_id = b.customer_id
  WHERE a.customer_id IS NULL;

• 注意用UNION ALL而不是UNION，这里不存在真正需要去重的情况，而且性能差别不小。

• 如果你用的是PostgreSQL或SQL Server，可以直接用FULL OUTER JOIN，但要注意两边JOIN键不能有NULL值，否则匹配出来的结果跟预想的可能不一样。

业绩同比计算放在JOIN后而非ON条件里

还有一个隐蔽的坑：有人会把(b.sales - a.sales) / a.sales这种计算直接扔进ON子句里，想着“只关联增长超过20%的记录”。结果不是语法报错，就是逻辑全乱——ON只管“怎么连”，不负责“算指标”。

实操上要注意：

• 所有同比、环比、完成率等计算一律放在SELECT或WHERE中。比如：SELECT ..., ROUND((sales_2023 - sales_2022) / NULLIF(sales_2022, 0), 3) AS yoy_rate。

• 务必用NULLIF(sales_2022, 0)来避免除以零的错误。在MySQL里默认会静默转成NULL，但若开启严格模式，直接中断查询。

• 如果打算筛选增长率大于0.2的记录，建议写在WHERE里。但要注意WHERE会过滤掉sales_2022为NULL或0的行，若想保留那些“从零起步”的新客户，改用HA VING（配合GROUP BY）或子查询更稳妥。

大表JOIN时性能断崖下降的隐形原因

两张销售表各有几千万行，按customer_id和year联合JOIN，执行时间从毫秒直接飙到分钟。一看EXPLAIN，rows预估严重偏大，甚至出现了Using temporary; Using filesort。这几乎是所有人都会遇到的性能瓶颈。

优化建议很明确：

• 确保JOIN键上有复合索引：CREATE INDEX idx_cust_year ON sales_table (customer_id, year);，顺序不能反——customer_id必须在前。

• 避免在JOIN字段上使用函数：比如ON YEAR(a.date) = b.year，会让索引失稳。可以在源表加一个计算列并索引（MySQL 5.7+支持函数索引）。

• 如果只是对比最近两年的数据，先用WHERE year IN (2022, 2023)缩小数据集再JOIN，比全表JOIN后WHERE过滤快得多。

跨年对比真正麻烦的不是语法，而是数据质量——同一客户在不同年份用不同编码，或者业绩归集口径变化，这些根本不是SQL能解决的。JOIN能对齐结构，但对不齐业务逻辑。