MySQL 8.0查询快插入慢：SELECT加INSERT后执行计划从range变ALL

• 优化器成本估算偏差：单独执行SELECT时，优化器判断通过索引的range扫描返回目标4万行数据成本更低；但加上INSERT后，优化器会重新评估执行计划——它可能错误估算了索引扫描+回表+去重的总开销，认为全表扫描（ALL）后直接处理过滤和去重的成本更优，最终选择了全表扫描，导致耗时暴增。
• 索引覆盖缺失：如果你的索引仅包含col1和col2，单独查询custid时需要回表获取数据。当结合INSERT操作时，回表的额外开销被放大，优化器可能认为全表扫描直接读取所有custid并过滤的方式更划算，从而放弃索引。
• 去重操作的影响：DISTINCT需要对结果集去重，单独查询时优化器可以在索引扫描过程中逐步完成去重；但INSERT场景下，优化器可能误以为全表扫描后一次性处理去重的效率更高，尤其是当它对去重所需的内存或排序成本估算不准时。

• 强制指定索引：在SELECT语句中显式强制使用索引，让优化器沿用高效的range扫描计划，示例：

  insert into table B select distinct custid from A force index(你的col1_col2索引名) where '2022-01-01' is between col1 and col2;
  

• 创建覆盖索引：建立包含col1、col2和custid的联合覆盖索引idx_col1_col2_custid，这样查询时无需回表，优化器无论在单独查询还是INSERT场景下都会优先选择索引扫描，示例：

  create index idx_col1_col2_custid on A(col1, col2, custid);
  

• 拆分操作：先将查询结果写入临时表，再从临时表插入目标表，规避优化器的错误计划选择，示例：

  create temporary table tmp_cust select distinct custid from A where '2022-01-01' is between col1 and col2;
  insert into table B select * from tmp_cust;
  drop temporary table tmp_cust;
  

• 调整优化器参数：可以尝试调整sort_buffer_size（增大排序缓冲区，让去重操作更高效）或optimizer_cost_model相关参数，引导优化器选择索引扫描，但此操作需谨慎，避免影响其他查询的执行计划。

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