PostgreSQL中EXPLAIN查询计划成本估算为何随测试执行顺序变化？

数据库查询优化器的成本估算核心依赖统计信息，哪怕你清空表再重新插入数据，之前的测试操作也可能留下影响统计逻辑的痕迹，导致优化器算出更高的成本。具体原因分这几点：

1. 统计信息未自动更新 #

多数数据库（比如PostgreSQL、MySQL）不会在每次表数据清空/插入后立刻同步更新统计信息。之前插入大量数据的测试会让统计信息记录下该表「曾有过更多行」的历史状态，哪怕当前表只插了少量测试数据，优化器可能还在沿用旧的统计值（比如平均行宽、数据分布特征）来计算成本，自然会得出偏高的结果。

举个例子：之前测试插了1000行，统计信息记了平均行宽150字节；后续测试只插10行，但统计信息没刷新，优化器还是按150字节的行宽估算扫描成本，数值自然上去了。

2. 表物理存储的残留特征 #

就算用TRUNCATE或DELETE FROM清空了数据，有些数据库的表空间会保留之前的物理痕迹——比如高水位线。优化器估算成本时，可能会参考表的物理磁盘块数（而非实际数据行数），误以为需要扫描更多磁盘块，从而抬高成本估算。

比如Oracle里，DELETE操作不会降低高水位线，后续插新数据后，表的物理块规模还是之前的大小，优化器会基于这个块数计算全表扫描成本。

3. 执行计划缓存的复用 #

部分数据库会缓存执行计划，之前针对大量数据生成的计划可能被存了下来。后续测试跑相同查询时，数据库可能直接复用旧计划（以及对应的成本估算值），不会重新基于当前的少量数据生成新计划。

比如PostgreSQL的计划缓存、旧版MySQL的查询缓存，都可能出现这种情况。

4. 自增/序列字段的状态残留 #

如果表用了自增ID或序列，之前的插入操作会让序列值持续增长，后续插入的新数据ID值会比初始状态大。有些数据库的统计信息会记录字段的极值，优化器可能认为字段范围更大，在做范围查询时估算的成本会更高。

比如PostgreSQL的pg_statistic表会记录字段的最大/最小值，序列增长后即便清空数据再插入，极值可能没同步更新，优化器会误以为数据分布范围更广。

对应的解决建议 #

• 每次测试前手动刷新统计信息：PostgreSQL用ANALYZE <table>，MySQL用ANALYZE TABLE <table>
• 针对高水位线问题，清空表后重建表或收缩表空间（比如Oracle的ALTER TABLE <table> SHRINK SPACE）
• 测试前清空执行计划缓存：PostgreSQL用DISCARD PLANS，MySQL用FLUSH TABLES
• 重置自增序列或序列值，确保新插入数据的字段范围符合测试预期

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