LEFT JOIN查询性能优化求助：20k行表关联耗时超15分钟

20k行的表关联出80k行结果却耗时15分钟，显然是索引策略或执行计划出了问题，咱们一步步来解决：

1. 给两张表添加覆盖式联合索引 #

这是最核心的优化点。你当前的JOIN依赖prod_id+month+year三个字段匹配，但单字段的prod_id索引完全没法支撑多字段的关联查询，数据库大概率在做全表扫描或者低效的索引回表。

• 给table1创建联合索引，同时包含查询需要的volume字段（避免回表操作）：

  -- 支持INCLUDE的数据库（如PostgreSQL、SQL Server）
  CREATE INDEX idx_table1_prod_year_month ON table1 (prod_id, year, month) INCLUDE (volume);
  -- MySQL/MariaDB（不支持INCLUDE，直接把字段加入索引）
  CREATE INDEX idx_table1_prod_year_month ON table1 (prod_id, year, month, volume);
  

• 给table2创建对应的联合索引，包含查询需要的wh和share字段：

  -- 支持INCLUDE的数据库
  CREATE INDEX idx_table2_prod_year_month ON table2 (prod_id, year, month) INCLUDE (wh, share);
  -- MySQL/MariaDB版本
  CREATE INDEX idx_table2_prod_year_month ON table2 (prod_id, year, month, wh, share);
  

  把year放在month前面是因为year的区分度更高，能更快缩小索引扫描范围。

2. 检查关联字段的类型一致性 #

如果table1和table2中的prod_id、month、year字段类型不一致（比如一个是INT，一个是VARCHAR），数据库会做隐式类型转换，直接导致索引失效，强制全表扫描。你可以用以下命令查看字段类型，确保两边完全匹配：

DESCRIBE table1;
DESCRIBE table2;

3. 更新表的统计信息 #

如果数据库的统计信息过时，优化器可能会选错执行计划（比如误以为表数据量很小，选择了低效的嵌套循环）。执行以下命令更新统计信息，让优化器生成更合理的执行计划：

-- MySQL/MariaDB
ANALYZE TABLE table1, table2;

-- PostgreSQL
ANALYZE table1, table2;

4. 调整数据库的JOIN缓冲配置 #

如果你的数据库JOIN缓冲太小，关联过程中需要频繁读写磁盘，也会拖慢速度。以MySQL为例，可以临时调大join_buffer_size（根据服务器内存调整，比如128M）：

SET GLOBAL join_buffer_size = 134217728; -- 128MB

注意：这个参数需要根据服务器总内存合理设置，避免占用过多系统资源。

额外确认：是否真的需要LEFT JOIN？ #

如果业务上table2中不存在的prod_id+month+year组合不需要保留，那把LEFT JOIN改成INNER JOIN会进一步提升性能——因为INNER JOIN的执行计划优化空间更大，数据库可以选择更高效的关联顺序。

内容的提问来源于stack exchange，提问作者Vlad Balan