数据库统计信息备份与还原技术实践
数据库查询优化器依赖于统计信息来生成高效的执行计划。统计信息描述了表中数据的分布特征，包括行数、数据块数量、列值分布直方图、空值比例等关键指标。当统计信息准确时，优化器能够选择最优的访问路径和连接顺序。当统计信息过时或不准确时，即使索引和表结构设计合理，查询性能也可能严重下降。
在生产环境中，统计信息的管理面临多个挑战。大型表的统计信息收集可能消耗大量系统资源和时间。业务高峰期无法执行统计信息收集操作。数据库迁移或升级后需要重建统计信息。测试环境需要复制生产环境的执行计划特征用于性能问题排查。统计信息的备份与还原能力正是为了解决这些问题而设计的。
本文将系统讲解数据库统计信息备份与还原的技术原理、实现方法和最佳实践，涵盖Oracle、PostgreSQL、SQL Server、达梦等主流数据库的具体操作。
一、统计信息备份与还原的价值
1.1 统计信息对查询性能的决定性影响
数据库查询优化器的核心任务是为SQL语句选择最佳执行计划。优化器基于统计信息评估不同执行路径的成本，包括全表扫描成本、索引扫描成本、连接操作成本等。统计信息的准确性直接决定了执行计划的质量。
当统计信息不准确时，优化器可能做出错误的选择。高选择性列被误判为低选择性，导致优化器选择全表扫描而非索引扫描。表行数估算偏差过大，导致嵌套循环和哈希连接之间的错误选择。列值分布信息缺失，导致连接基数估算严重偏差。这些问题最终表现为SQL语句响应时间从毫秒级变为分钟级。
1.2 为什么需要备份统计信息
统计信息的备份与还原在多个场景下具有重要价值。
执行计划回退是常见场景。新的统计信息收集后，某些查询的执行计划发生退化。通过还原之前的统计信息，可以快速恢复查询性能，而不需要等待下一次统计信息收集或执行计划固化。
数据库迁移场景中，将生产环境的统计信息迁移到测试环境，使测试环境能够复现生产环境的执行计划特征。这对于性能问题排查和变更影响评估至关重要。
数据库升级场景中，升级后系统需要重新收集统计信息，这个过程对于大库可能耗时数小时甚至数天。通过还原备份的统计信息，可以显著缩短升级窗口。
灾难恢复场景中，当系统故障导致统计信息丢失或损坏时，可以从备份中恢复。
1.3 统计信息备份与ANALYZE执行的时间权衡
在数据库迁移或升级场景中，统计信息的还原与重新执行ANALYZE之间存在显著的时间差异。
对于大型数据库，全量执行ANALYZE可能需要数小时到数天。以10TB规模的数据库为例，全量ANALYZE耗时通常在8到24小时之间，取决于表数量、数据分布和系统资源。而统计信息还原操作通常在分钟级完成，耗时差异可达一到两个数量级。
Postgres Pro官方文档明确指出，使用dump_stat模块备份和恢复统计信息可以显著减少大型数据库的停机时间。在迁移场景中，将原始统计信息迁移到新服务器，而不是对整个数据库集群执行ANALYZE命令，是一种经过验证的高效方案。
二、统计信息的存储与生命周期管理
2.1 统计信息的存储位置
不同数据库系统将统计信息存储在不同的系统表和视图中。
在Oracle数据库中，统计信息存储在数据字典中。基表包括WRIOPTSTATTABHISTORY存储表统计信息历史，WRIOPTSTATTABHISTORY存储表统计信息历史，WRI_OPTSTAT_IND_HISTORY存储索引统计信息历史，WRI$_OPTSTAT_HISTHEAD_HISTORY存储列直方图历史。相关视图包括DBA_TAB_STATS_HISTORY、DBA_IND_STATS_HISTORY、DBA_TAB_COL_STATISTICS等。
在PostgreSQL数据库中，统计信息存储在系统目录中。pg_statistic存储列级统计信息，pg_statistic_ext存储扩展统计信息。pg_class存储表级统计信息，包括relpages和reltuples。
在SQL Server数据库中，统计信息存储在内部系统表中。相关视图包括sys.stats、sys.stats_columns、sys.dm_db_stats_properties等。
在达梦数据库中，统计信息通过系统包进行导出和导入，存储在用户指定的舞台表中。
2.2 统计信息的保留策略
Oracle数据库采用基于时间保留周期的自动管理机制。默认情况下，数据库保留统计信息历史31天，超过此期限的统计信息会被自动清理。可以通过DBMS_STATS.ALTER_STATS_HISTORY_RETENTION过程修改保留周期。在年度报表等周期性查询场景中，可能需要将保留周期延长至366天，以便访问上一年同期的执行计划。
DBA_TAB_STATS_HISTORY视图记录了表统计信息的修改历史，包括每次统计信息收集的时间戳。DBA_OPTSTAT_OPERATIONS视图记录了统计信息操作的完整历史。通过查询这些视图，可以确定可用于还原操作的时间戳。
PostgreSQL的统计信息不提供自动历史保留机制。统计信息的备份需要通过导出功能手动完成。
2.3 统计信息的自动清理与手动清理
Oracle数据库在STATISTICS_LEVEL参数设置为TYPICAL或ALL时，自动启用统计信息历史清理。清理策略为保留期由ALTER_STATS_HISTORY_RETENTION设置决定，清理范围为当前时间减去保留期之前的所有历史。可以通过DBMS_STATS.PURGE_STATS过程进行手动清理。执行DBMS_STATS.PURGE_STATS(SYSDATE-7)将清理七天前的统计信息历史。
三、Oracle数据库统计信息备份与还原
3.1 统计信息的历史保留机制
Oracle数据库自动保存统计信息的修改历史。每当统计信息被更新时，旧版本会被保留在数据字典中。当新收集的统计信息导致执行计划退化时，可以还原到之前的统计信息版本。
还原操作的时间点精度可以达到秒级。DBMS_STATS.RESTORE_*_STATS过程接受时间戳参数，将统计信息还原到指定时间点的状态。例如，如果统计信息在8月10日和8月20日被收集，8月24日DBA判断当前统计信息可能导致优化器生成次优计划，可以在8月25日还原到8月10日的统计信息。
3.2 还原操作的适用场景
还原统计信息适用于以下情况。希望恢复优化器到更早日期的行为，例如某次统计信息更新后关键查询性能下降，需要回退到更新前的状态。希望数据库自动管理统计信息的保留和清理，无需手动维护历史备份。
导出统计信息比还原更适用的场景包括：需要使用多套统计信息进行对比实验，需要在不同数据库之间迁移统计信息，例如从生产系统迁移到测试系统。需要将已知良好的统计信息保留超过还原保留期。
3.3 还原操作的限制
DBMS_STATS.RESTORE_*_STATS过程存在若干限制。无法还原用户自定义统计信息。使用ANALYZE命令收集的统计信息不保留历史版本，无法通过RESTORE过程还原。删除表会清除自动直方图功能的工作负载数据和统计信息历史，Oracle推荐使用TRUNCATE代替DROP和RECREATE来清空表数据。如果表在回收站中，闪回表操作也会恢复相应的统计信息。
3.4 还原操作的具体步骤
使用DBMS_STATS.RESTORE_TABLE_STATS还原表统计信息的完整流程如下。
第一步，查询统计信息历史以确定还原的目标时间点。
SELECT TABLE_NAME, TO_CHAR(STATS_UPDATE_TIME,'YYYY-MM-DD:HH24:MI:SS') AS STATS_MOD_TIME FROM DBA_TAB_STATS_HISTORY WHERE TABLE_NAME='ORDERS' AND OWNER='OE' ORDER BY STATS_UPDATE_TIME DESC;第二步，执行还原操作。
BEGIN DBMS_STATS.RESTORE_TABLE_STATS( 'OE','ORDERS', TO_TIMESTAMP('2012-08-10:11:06:20','YYYY-MM-DD:HH24:MI:SS') ); END; /可以指定两个统计信息收集时间点之间的任意时间，DBMS_STATS会将统计信息还原到指定时间点的状态。
3.5 统计信息保留期的管理
查询当前保留期设置。
DECLARE v_stats_retn NUMBER; v_stats_date DATE; BEGIN v_stats_retn := DBMS_STATS.GET_STATS_HISTORY_RETENTION; DBMS_OUTPUT.PUT_LINE('The retention setting is ' || v_stats_retn || '.'); v_stats_date := DBMS_STATS.GET_STATS_HISTORY_AVAILABILITY; DBMS_OUTPUT.PUT_LINE('Earliest restore date is ' || v_stats_date || '.'); END; /修改保留期。
BEGIN DBMS_STATS.ALTER_STATS_HISTORY_RETENTION(366); END; /四、PostgreSQL统计信息备份与还原
4.1 dump_stat模块的设计目的
PostgreSQL的统计信息存储在系统目录中，默认不提供内置的备份和还原机制。dump_stat模块填补了这一空白。该模块提供了将pg_statistic系统表内容导出为INSERT语句的功能，这些语句可以在兼容的数据库中执行以恢复统计信息。
在数据库迁移或升级场景中，dump_stat可以替代全量ANALYZE操作，显著缩短停机时间。Postgres Pro官方文档指出，执行dump/restore时，可以使用dump_stat将原始统计信息迁移到新服务器，而不是对整个数据库集群运行ANALYZE命令，这可以显著减少大型数据库的停机时间。
4.2 dump_stat的安装与启用
dump_stat模块包含在Postgres Pro中。安装后需要执行CREATE EXTENSION命令启用。
CREATE EXTENSION dump_stat;该扩展必须在源端和目标端数据库中都安装，因为生成的INSERT语句依赖于扩展提供的函数。
4.3 统计信息导出函数
dump_statistic函数支持多种粒度的导出操作。
导出整个数据库的所有统计信息。
psql -XAtq -c "SELECT dump_statistic()" dbname > dump_stat.sql导出指定schema的统计信息。
psql -XAtq -c "SELECT dump_statistic('public')" dbname > dump_stat.sql导出指定表的统计信息。
psql -XAtq -c "SELECT dump_statistic('public.orders')" dbname > dump_stat.sql导出操作的输出是INSERT语句，每个pg_statistic元组对应一条INSERT语句。重定向psql输出到文件即可保存统计信息。
4.4 统计信息导入的注意事项
导入统计信息时需要注意以下事项。pg_statistic表的定义偶尔会发生变化，生成的dump可能与未来版本的Postgres Pro不兼容。目标数据库必须安装dump_stat扩展。统计信息还原后建议验证关键查询的执行计划是否符合预期。
4.5 PostgreSQL 19的扩展统计信息支持
PostgreSQL 19实现了统计信息导出和恢复的完整闭环。新增pg_restore_extended_stats函数用于还原扩展统计信息，即通过CREATE STATISTICS创建的对象。该函数在设计上与表级、列级统计信息还原函数高度相似，专门用于扩展统计信息对象的还原。
pg_dump工具集成了该函数。在指定--statistics参数时，能够检测扩展统计信息数据并将其包含在转储文件中。目前可转储的扩展统计类型包括n_distinct和dependencies。
三个还原函数的定位如下。pg_restore_relation_stats用于还原表的整体统计信息，如行数和数据页数。pg_restore_attribute_stats用于还原列的详细统计，如直方图和高频值，直接影响查询优化器的执行计划选择。pg_restore_extended_stats用于还原CREATE STATISTICS创建的扩展统计信息。
典型使用场景包括测试环境对齐，导出生产统计信息注入测试库，无需模拟海量数据即可获得与生产一致的查询计划。集群升级场景中，升级后直接还原统计信息，避免执行耗时的ANALYZE。故障调试场景中，将生产统计信息导入本地环境，还原生产查询执行逻辑，快速定位性能问题。
五、SQL Server统计信息管理
5.1 维护计划中的统计信息更新
SQL Server提供了维护计划功能来管理数据库的例行维护任务，包括统计信息更新。维护计划创建为SQL Server代理作业，可以按预定时间间隔自动运行。
维护计划中的更新统计信息任务可以更新查询优化器用于生成执行计划的列和索引统计信息。准确的统计信息对于查询优化器做出最佳决策至关重要。可以配置要扫描的表和索引范围，以及扫描的数据行百分比或数量。默认采样率通常足够，但在某些场景下需要更详细的统计信息。
5.2 统计信息更新的最佳实践
维护计划的最佳实践包括以下几点。
将备份保留期与一致性检查窗口对齐。如果每周执行一致性检查，应保留足够的备份历史记录，以便从一致性检查期间检测到的潜在损坏中恢复。
为每种类型的工作创建单独的维护计划。为系统数据库和用户数据库分别创建备份计划，为特别大型的用户数据库创建单独的维护计划。
在维护计划中，重新生成索引操作也会更新统计信息。DBA可以交错大型数据库的备份，每周执行完整备份，结合差异备份和事务日志备份，实现精细的恢复点目标。
5.3 统计信息与索引维护的关系
在SQL Server中，索引维护和统计信息维护紧密相关。重新生成索引会自动更新统计信息。重新组织索引不会更新统计信息，需要单独执行统计信息更新操作。数据库一致性检查CHECKDB也是维护计划的重要组成部分，是检测数据库损坏的唯一方法。
六、达梦数据库统计信息备份与还原
6.1 统计信息舞台表
达梦数据库通过舞台表来管理统计信息的导入导出。使用DBMS_STATS.CREATE_STAT_TABLE创建舞台表，使用DBMS_STATS.DROP_STAT_TABLE删除舞台表。舞台表存储了从源数据库导出的统计信息，可以传输到目标数据库进行还原。
6.2 统计信息导出操作
在源数据库执行统计信息导出。首先创建舞台表，然后遍历目标schema的所有表，调用DBMS_STATS.EXPORT_TABLE_STATS将统计信息导出到舞台表，可以指定统计ID标识导出批次。导出后可以使用达梦导出工具dexp将舞台表导出为DMP文件进行传输。
6.3 统计信息导入操作
在目标数据库执行统计信息导入。创建同名的舞台表，使用达梦导入工具dimp将DMP文件导入到舞台表。调用DBMS_STATS.IMPORT_TABLE_STATS将统计信息从舞台表还原到目标表。还原操作前建议重建系统包，特别是使用替换bin目录方式升级后的数据库。
七、统计信息备份还原的工程实践
7.1 制定统计信息备份策略
统计信息的备份策略应与数据库的整体备份策略协调一致。关键考虑因素包括统计信息变更的频率、业务允许的统计信息收集窗口、统计信息失效后对查询性能的影响容忍度。
建议将统计信息备份纳入标准运维流程。在每次大规模统计信息收集后保存历史快照。在数据库版本升级前备份统计信息。在迁移演练中包含统计信息还原验证步骤。
7.2 统计信息还原的验证方法
统计信息还原后应进行验证，确保还原操作达到预期效果。验证方法包括检查关键查询的执行计划是否恢复，对比还原前后的统计信息值，运行代表性SQL语句的性能测试。
在还原操作前，记录当前统计信息的状态以便必要时回退。对于关键业务系统，建议在测试环境先验证还原操作的效果。
7.3 统计信息备份还原的安全考虑
统计信息备份文件包含数据库的模式和分布信息，应妥善保管。导出文件应存放在安全的存储位置，遵循与数据库备份相同的安全策略。在传输统计信息文件时使用加密通道。统计信息的访问应遵循最小权限原则。
八、总结
统计信息是数据库查询优化器的核心输入，其准确性直接影响SQL语句的执行计划质量和查询性能。统计信息的备份与还原能力为数据库管理员提供了应对统计信息相关性能问题的关键工具。
Oracle数据库通过DBMS_STATS包的RESTORE系列过程实现了统计信息的历史保留和还原，默认保留31天历史。PostgreSQL通过dump_stat模块实现了统计信息的导出和导入，PostgreSQL 19进一步扩展了对扩展统计信息的支持。SQL Server通过维护计划提供了统计信息更新的自动化管理。达梦数据库通过舞台表机制实现了统计信息的导入导出。
在实际运维中，建议将统计信息备份纳入标准运维流程，在大规模统计信息收集、数据库迁移、版本升级等关键操作前后进行统计信息的备份和验证，确保在统计信息相关性能问题出现时能够快速恢复。
