JOIN年份字段类型不一致会导致匹配失败、结果为空，应统一用YEAR()或显式转换；MySQL不支持FULL OUTER JOIN，需用UNION ALL模拟；同比计算须放SELECT/WHERE而非ON；大表JOIN需复合索引且避免函数操作。
JOIN时年份字段类型不一致导致结果为空
常见现象是执行LEFT JOIN后，本该有数据的行全为NULL，尤其当一张表用INT存年份（如2023），另一张用CHAR(4)或DATE字段（如'2023-01-01'）。数据库不会自动隐式转换年份部分，匹配直接失败。
实操建议：
- 统一用
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年有、2022年没有的新客户，本质需要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快，除非真要去重——跨年对比里重复客户ID不可能出现 - 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)代替直接除，否则Division by zero错误在MySQL里默认静默转成NULL，但在严格模式下会中断查询 - 如果要筛选增长率>0.2的记录，写在
WHERE里，但注意WHERE会过滤掉sales_2022为NULL或0的行——若需保留这些“从零起步”的新客户，改用HAVING（配合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过滤快得多
跨年对比真正麻烦的不是语法，而是数据质量——比如同一客户在不同年份用不同编码，或者业绩归集口径变化。JOIN能对齐结构，但对不齐业务逻辑。
