SELECT执行3秒返回零行，添加INSERT插入零行却耗时2分钟是什么原因

• 执行计划差异：纯SELECT查询返回零行时，优化器会启动短路执行逻辑，仅需验证是否存在符合条件的行、无需扫描全量数据即可提前终止执行；添加INSERT语句后，优化器默认需要准备全量待写入数据，会放弃短路逻辑选择全量扫描的执行计划，哪怕最终结果集是空。
• CTE（公共表达式）物化策略差异：多数数据库（PostgreSQL/MySQL 8.0+/Oracle等）对只读SELECT的CTE默认采用内联展开策略，直接将CTE逻辑嵌入主查询做谓词下推优化；涉及写入操作时，优化器会优先选择将CTE结果先物化到临时表，若CTE逻辑涉及大表扫描，哪怕最终结果为空，物化过程的全表扫描也会产生大量耗时。
• 目标表额外开销前置：若目标表存在外键约束、INSERT级触发器、全文索引等附加逻辑，部分数据库优化器会在执行INSERT前提前加载关联表数据、触发前置校验逻辑，哪怕最终没有数据写入也会产生额外开销。
• 统计信息偏差：数据库表的统计信息过时会导致优化器对INSERT场景的行计数估算错误，误判需要写入大量数据而选择适配大写入量的低效执行计划。

1. 先对比两条语句的执行计划定位具体差异，对应数据库执行计划命令示例：

-- PostgreSQL/MySQL 8.0+ 查看带实际执行统计的计划
EXPLAIN ANALYZE 
with t1 as (...)
select t1;

EXPLAIN ANALYZE
with t1 as (...)
insert into myscheme.sometable
select t1;

2. 强制CTE走内联优化：若确认是CTE物化导致的耗时，可改写SQL将CTE替换为嵌套子查询，或添加数据库对应的查询Hint强制CTE不物化，例如PostgreSQL可声明CTE为NOT MATERIALIZED：

with t1 AS NOT MATERIALIZED (...)
insert into myscheme.sometable
select t1;

3. 清理目标表不必要的附加逻辑：检查目标表是否存在未使用的INSERT触发器、冗余外键约束，确认后可删除或调整触发逻辑为行级触发（仅当有数据插入时才执行）。
4. 修正统计信息：更新涉及表的统计信息，让优化器可以准确估算行数选择最优计划，示例命令：

-- MySQL
ANALYZE TABLE 表名;
-- PostgreSQL
ANALYZE 表名;
-- Oracle
DBMS_STATS.GATHER_TABLE_STATS('用户名','表名');

5. 加查询Hint强制复用SELECT的执行计划：如果确认SELECT的执行计划效率更高，可添加对应Hint强制INSERT语句复用该执行计划。

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