数据库统计信息更新频率影响执行计划选择

数据库统计信息更新频率直接决定了查询优化器能否选出正确的执行计划。简单说，统计信息就是数据库对表中数据分布的"快照"，如果这个快照太旧，优化器就会基于错误的假设来选择执行计划，导致全表扫描代替索引查找、错误的连接顺序、不合理的并行度设定等一系列性能问题。解决这个问题的核心思路是：根据数据变更量和业务特征，建立分层、自适应的统计信息更新策略，而不是一刀切地定时全量更新。

很多DBA和开发者在排查慢查询时，第一反应是查索引、查SQL写法，却忽略了统计信息这个隐藏的"幕后黑手"。实际上，在生产环境中大约30%到40%的执行计划异常，根源都在统计信息失真。今天这篇文章，我会从原理、影响、检测方法到具体的优化策略，把这个问题讲透。

统计信息是数据库引擎维护的一组元数据，记录了表和索引的关键分布特征。主要包括：行数（cardinality）、列值的唯一值数量（distinct values）、值的频率分布（histogram）、列的最大最小值、空值比例等。优化器在生成执行计划时，会依赖这些数据来估算每一步操作的代价（cost），代价最低的计划就是最终被选中的执行计划。

举个具体例子。假设一张订单表有1000万行数据，其中status='已完成'的有800万行，status='待处理'的有200万行。如果统计信息还停留在表只有100万行的时候，优化器可能认为两个值的分布是均匀的，于是选择全表扫描。但实际上，如果你查询status='待处理'，用索引只需要扫描200万行，效率差距是几十倍。这就是统计信息失真带来的直接后果。

统计信息更新频率的问题，本质上是一个"太旧"和"太频繁"之间的平衡。频率太低，信息失真；频率太高，更新本身消耗资源，还可能导致执行计划频繁抖动。具体来说，会引发以下几类典型问题：

第一，执行计划退化。原本走索引的查询突然变成全表扫描，查询时间从毫秒级跳到秒级甚至分钟级。这种情况在数据批量导入、大批量删除之后特别常见。

第二，连接顺序错误。多表关联时，优化器根据统计信息估算每张表的中间结果集大小，从而决定驱动表和被驱动表。如果统计信息偏差大，可能选了一张大表做驱动表，导致嵌套循环变成笛卡尔积级别的灾难。

第三，并行度设定不合理。有些数据库会根据统计信息决定是否启用并行执行以及并行度设多少。统计信息过时可能导致该并行的不并行，或者并行度过高抢占资源。

第四，执行计划抖动（plan regression）。统计信息每次更新后，优化器可能重新选择不同的计划，导致同一个SQL今天快明天慢，排查起来极其困难。

主流数据库对统计信息的处理方式各有不同，理解这些差异对制定策略非常关键。

MySQL（InnoDB引擎）默认在表数据变化超过一定比例时自动触发统计信息重新计算，但这个阈值并不透明，而且对大表的采样可能不够充分。MySQL 8.0引入了直方图统计（histogram statistics），支持多桶分布，但默认是关闭的，需要手动开启。

PostgreSQL使用ANALYZE命令手动或自动更新统计信息，自动更新由autovacuum触发。PostgreSQL的统计信息默认采样300行（可通过default_statistics_target调整），对于数据分布极不均匀的列，300行采样可能严重不足。

SQL Server的统计信息分为全扫描统计和采样统计，默认是采样。SQL Server还有一个"自动更新统计信息"的选项（AUTO_UPDATE_STATISTICS），默认开启，触发条件是表的20%数据发生变化加上500行。但对于大表，20%的阈值可能太高了。

Oracle的统计信息管理更加精细，支持增量统计、锁定统计、待发布统计等高级特性，还可以设置统计信息的保留期限（STALE_PERCENT）。

不要等到出了性能问题才去查统计信息。主动监控才是正确姿势。以下是几种实用的检测方法：

方法一：查看统计信息的最后更新时间。大多数数据库都提供系统视图或命令来查看。例如在SQL Server中：

SELECT 
    OBJECT_NAME(object_id) AS table_name,
    name AS stat_name,
    STATS_DATE(object_id, stats_id) AS last_updated,
    modification_counter
FROM sys.stats
WHERE OBJECT_NAME(object_id) = 'your_table_name';

方法二：对比实际行数和统计信息中的行数。如果偏差超过20%，基本可以判断统计信息已经失真。

方法三：观察执行计划的变化。如果同一个SQL的执行计划突然变了，而且变差了，大概率是统计信息更新导致的。可以通过查询执行计划缓存来追踪这种变化。

方法四：使用数据库自带的健康检查工具。比如SQL Server的sp_updatestats、PostgreSQL的pg_stat_user_tables、Oracle的DBMS_STATS包都提供了相关的诊断能力。

这是整篇文章最核心的部分。我的建议是建立一个"分层+自适应"的策略体系，而不是简单地设置一个定时任务。

第一层：高频变更表，实时或准实时更新。对于每天数据变化量超过10%的核心业务表（如订单表、交易流水表），建议在批量操作完成后立即触发统计信息更新，或者设置很短的更新间隔（比如每小时）。可以在ETL流程的最后一步加上更新统计信息的命令。

第二层：中等变更表，按需更新。对于数据变化量在1%-10%之间的表，可以设置每天一次的定时更新，放在业务低峰期执行。同时开启数据库的自动更新机制作为兜底。

第三层：低频变更表，定期维护。对于配置表、字典表等几乎不变的表，一周甚至一个月更新一次就够了，没必要浪费资源。

具体的操作建议如下：

对于MySQL，可以这样配置自动更新：

SET GLOBAL innodb_stats_auto_recalc = ON;
SET GLOBAL innodb_stats_persistent_sample_pages = 64;

对于SQL Server，可以针对特定表调整自动更新的触发阈值：

ALTER DATABASE your_db SET AUTO_UPDATE_STATISTICS_ASYNC ON;
UPDATE STATISTICS your_table WITH FULLSCAN, NORECOMPUTE;

对于PostgreSQL，可以调整采样精度：

ALTER TABLE your_table ALTER COLUMN your_column SET STATISTICS 1000;
ANALYZE your_table;

更新统计信息本身不是免费的。全表扫描统计信息（FULLSCAN）对大表来说可能需要几分钟甚至更长时间，期间会产生大量I/O，影响在线业务。所以有几个原则必须遵守：

原则一：尽量用采样而非全扫描。对于亿级大表，10%甚至5%的采样通常就能得到足够准确的统计信息。除非数据分布极度不均匀，否则没必要每次都全扫描。

原则二：错峰执行。把统计信息更新放在凌晨或者业务低谷期，避免和在线查询争抢资源。

原则三：锁定关键表的统计信息。如果某个执行计划已经验证是最优的，可以锁定统计信息，防止自动更新导致计划回退。SQL Server和Oracle都支持这个功能。

原则四：监控更新过程。记录每次统计信息更新的耗时和对系统的影响，持续优化更新策略。

我曾经参与过一个电商平台的性能优化项目。他们的商品搜索接口在大促期间响应时间从200ms飙升到8秒。排查发现，商品表在大促前导入了大量新商品，统计信息还是大促前的旧数据，优化器认为商品表只有50万行，选择了全表扫描。实际上商品表已经有500万行了。

解决方案是：在商品导入的ETL流程末尾加上统计信息更新，同时对商品表的关键过滤列（类目、价格区间、品牌）设置更高的采样精度。另外，把自动更新的触发阈值从默认的20%调低到5%。优化之后，搜索接口稳定在300ms以内。

数据库统计信息更新频率是一个容易被忽视但影响巨大的性能因素。核心要点归纳如下：统计信息是优化器做决策的基础，失真会直接导致执行计划错误；不同数据库机制不同，需要针对性配置；不要一刀切，要根据数据变更量分层管理；采样优先、错峰执行、监控闭环是三条铁律。把统计信息管理纳入日常运维体系，而不是出了问题才救火，这才是真正的长期主义。

最后提醒一句，统计信息只是影响执行计划的因素之一，参数设置、索引设计、SQL写法、硬件资源同样重要。但如果你的慢查询查了一圈都找不到原因，不妨先看看统计信息的最后更新时间，也许答案就在那里。