在数据库运维的日常中，有一类故障极其狡猾：SQL语句没有变，表结构没有变，数据量甚至也没有发生突变，但某条查询突然从毫秒级退化到了秒级甚至分钟级。排查索引，存在且可用；排查锁，没有阻塞；排查磁盘IO，也在正常范围。此时，绝大多数开发者会把目光投向网络、硬件、并发参数，却很少有人会想到一个藏在优化器背后的"隐形杀手"——过期的统计信息。数据库优化器并不知道表中到底有多少行数据、每一列的值域分布如何、不同列之间是否存在相关性，它所依赖的一切判断依据，全部来自统计信息。如果这些信息是陈旧的、失真的，那么优化器做出的每一个决策都可能是错的，而执行计划就是这些错误决策的最终产物。

要理解统计信息为什么会过期，首先需要知道它是怎么被采集的。大多数关系型数据库会在创建表、创建索引时自动采集一次初始统计信息，之后则依赖自动更新机制来保持数据的新鲜度。自动更新通常由两种事件触发：一是数据量变化达到一定阈值，比如表中新增或删除的行数超过了某个百分比；二是达到了固定的时间间隔。这两种触发机制看似合理，但在实际生产环境中却暗藏大量盲区。对于一个日增数据量巨大的订单表，如果自动更新阈值设得过高，那么在数据量已经翻倍的情况下，统计信息可能仍然停留在几天前的状态。而对于一个数据量变化不大但值域分布已经发生显著偏移的表——比如某个状态字段从原本绝大多数为"已完成"变成了绝大多数为"进行中"——基于行数阈值的更新机制根本不会被触发，因为总行数几乎没变。这就是统计信息过期最典型的两种场景：一是数据量剧变但未达阈值，二是值域分布偏移但行数稳定。

统计信息的核心组成包括三个部分：表的总行数、每一列的值域分布（通常以直方图或频率统计的形式呈现）、以及多列之间的相关性信息。当这些数据中的任何一项严重失真时，优化器的代价估算就会出现偏差，而代价估算是执行计划生成的唯一依据。最常见的劣化模式有以下几种。第一种是行数估算错误导致的连接顺序错误。在多表连接查询中，优化器会根据各表的行数估算来决定驱动表和被驱动表，小表驱动大表是基本原则。如果一张表的实际行数已经从十万增长到了一千万，但统计信息仍然显示十万行，优化器就会错误地将这张大表选为驱动表，导致嵌套循环连接的循环次数暴增，查询时间从秒级飙升到分钟级。第二种是值域分布失真导致的索引选择错误。假设一个用户状态字段有"活跃"和"沉默"两个值，历史上"活跃"用户占百分之九十，"沉默"占百分之十，统计信息也准确记录了这一分布。但经过一次运营活动后，"沉默"用户的比例突然上升到百分之六十，而统计信息未及时更新。此时查询"沉默"用户时，优化器仍然按照百分之十的选择性去估算，认为走索引扫描比全表扫描更优，但实际上百分之六十的数据都需要回表，全表扫描反而更快。第三种是直方图缺失导致的范围查询估算偏差。对于带有范围条件的查询，如果列上没有直方图，优化器只能做均匀分布假设，这在数据分布不均匀时会产生巨大误差。比如按时间范围查询最近一天的订单，如果订单量在某些时段极度集中，均匀分布假设会严重低估实际返回的行数。

从症状上看，统计信息过期导致的查询劣化有几个非常典型的特征，掌握这些特征可以快速缩小排查范围。第一个特征是突然劣化。统计信息不像索引损坏那样会导致查询直接报错，它的影响是渐进的、隐蔽的，但一旦触发阈值，性能下降往往是断崖式的。昨天还正常，今天突然慢了十倍，这种"突变"几乎可以排除硬件、网络、并发等缓变因素，直接指向执行计划的变化。第二个特征是执行计划发生了明显变化。如果能获取到劣化前后的执行计划对比，会发现索引选择变了、连接顺序变了、扫描方式从索引扫描变成了全表扫描。这种变化不是渐进的优化调整，而是方向性的错误。第三个特征是表的数据量或数据分布确实发生过变化。这一点需要结合业务日志来确认，比如最近是否有批量数据导入、是否有业务规则变更导致某个字段的值域发生偏移。如果这三个特征同时满足，统计信息过期的概率就非常高了。

排查的第一步，永远是获取当前的执行计划并与历史正常状态进行对比。大多数数据库都提供了执行计划的查看能力，重点关注几个关键节点：访问方式是索引扫描还是全表扫描、连接方式是嵌套循环还是哈希连接、驱动表的选择是否合理、行数估算值与实际返回行数的差距有多大。如果行数估算值与实际值相差一个数量级以上，那几乎可以确定是统计信息的问题。第二步是检查统计信息的最后更新时间。不同数据库的系统表或系统视图中都记录了各表、各列统计信息的最后采集时间，将这个时间与当前时间对比，如果间隔过长——比如超过一天甚至一周——而期间数据量又有明显变化，那就是确凿的证据。第三步是手动触发统计信息采集，然后观察查询性能是否立即恢复。这是最直接的验证手段，如果采集后查询立刻变快，那就百分之百确认了根因。

但仅仅知道统计信息过期是不够的，更深层的问题是：为什么自动更新机制没有生效？这就需要对自动更新策略进行审计。首先检查自动更新的触发阈值是否合理。很多数据库的默认阈值是基于总行数的百分比，对于小表来说这个百分比可能意味着几百行的变化就会触发更新，但对于大表来说可能需要几百万行的变化才会触发。如果业务的数据增长模式恰好落在阈值的盲区，那么自动更新就形同虚设。其次检查是否存在禁用自动统计信息更新的情况。在一些对性能极度敏感的场景中，开发者可能会手动关闭自动更新以避免采集过程对业务的影响，但如果忘记重新开启或定期手动采集，统计信息就会持续老化。再次，需要关注采样精度的问题。为了加快采集速度，很多数据库在大表上会采用采样而非全量扫描的方式来生成统计信息。采样在数据量均匀分布时效果很好，但当数据分布高度偏斜时，采样结果可能严重失真。比如一个有十亿行的表，采样百分之一得到一千万行的样本，如果这一千万行恰好没有覆盖到某些罕见但关键的值域区间，那么生成的直方图就是有缺陷的。

在排查过程中还有一个容易被忽略的维度：多列相关性。优化器在生成执行计划时，不仅考虑单列的选择性，还会考虑多列条件之间的相关性。比如"城市等于某值且年龄大于某值"这个条件，如果城市和年龄之间存在强相关性——比如某个城市的用户年龄普遍偏大——那么两个条件的联合选择性就不等于各自选择性的乘积。如果统计信息中没有记录这种相关性，优化器就会独立估算每个条件的选择性然后相乘，导致估算结果严重偏离实际。这种问题在复合查询中尤为突出，也是很多开发者在排查时反复检查单列统计信息却找不到问题的原因。解决方案是创建多列统计信息或扩展统计信息对象，让优化器能够感知列之间的关联关系。

对于已经确认是统计信息问题的场景，修复手段分为短期和长期两个层面。短期最快的修复方式就是手动触发统计信息的全面采集，对于核心表甚至可以强制全量扫描而非采样，以确保精度。但这只是治标，长期方案需要从自动更新策略入手。一种做法是将自动更新的阈值调低，让触发更频繁；另一种做法是针对关键表建立定期采集的任务，在业务低峰期固定执行。更进阶的做法是监控统计信息的新鲜度，将其纳入数据库健康检查的指标体系，当某张表的统计信息超过一定时间未更新且数据量变化超过阈值时，自动告警甚至自动触发采集。对于数据量巨大且变化频繁的表，还可以考虑使用增量统计信息采集的方式，只对变化的部分进行重新估算，在精度和性能之间取得平衡。

从更宏观的视角来看，统计信息过期问题本质上反映的是数据库优化器的一个根本性矛盾：它需要准确的数据分布信息来做出最优决策，但获取这些信息本身是有代价的，而且信息永远是对过去的快照而非实时反映。这个矛盾无法被彻底消除，只能被管理。优秀的数据库运维不是等问题发生后再去救火，而是建立一套对统计信息健康度的持续监控机制，在劣化发生之前就将其纠正。对于开发工程师而言，理解统计信息的采集原理、过期机制和对执行计划的影响路径，是排查查询性能问题时不可或缺的底层能力。很多时候，一条慢查询的背后不是SQL写得不好，不是索引缺失，而是优化器被过期的统计信息"骗"了，做出了一个从数据上看完全合理、但从现实来看完全错误的决定。识别出这种"合理的错误"，正是资深工程师与普通开发者之间的分水岭。