作为DBA的你，遇到问题无从下手，除了在问题面前徘徊，还能如何选择？如果你一次或多次遇到该问题还是无法解决，又很懊恼，该如何排忧呢？关注公众号，关注《包拯断案》专栏，让小编为你排忧解难~

说了这么多理论，想必实战更让你心动。那我们就拿一个真实案例进行分析——某国有大型商业银行中，某一业务系统的数据库CPU资源使用量瞬间激增，且持续时间为1分钟，这种问题该如何快速分析处理：

1、故障发生场景

在项目现场兢兢业业进行数据库环境部署的你，突然收到告警，发现某个系统CPU资源使用量瞬间激增，消耗了较多的系统资源，导致数据库集群查询性能下降，DBA心中警铃大作，立马着手排查。

2、故障排查分析

1）收到告警后，登录数据库后台查看当前数据库状态。经初步确认，没有发现高耗时的SQL。与报障人员确认后，初步判断问题可能源于历史慢查询SQL，导致了CPU 资源占用量的激增。

2）查看当前数据库的慢查询日志，发现在 CPU 使用率升高的时间点里，数据库在频繁执行一条慢SQL语句。

3）随后检查该慢查询的执行计划，发现该查询未使用索引，而是选择了高系统资源消耗的全表扫描方式，如下图：

4）之后检查与该查询相关的表索引和统计信息，如下图：

5）根据上述输出信息，我们可以得出结论：该系统CPU资源突然激增问题，源于高并发执行的慢查询，其中一个主要原因是查询表的统计信息不准确，导致查询优化器选择了不合适的执行计划（全表扫描）。

全表扫描对于大表而言消耗了较多系统资源，导致查询性能下降。因此，用户端无法在期望时间内获得结果，导致用户不断尝试调用该慢查询，最终在操作系统层面引发CPU资源占用激增的问题。 

3、问题复现

在测试环境中，我们执行以下步骤来创建一个大型表，以验证统计信息的不准确性如何导致优化器选择错误的执行计划。

1）禁用自动更新统计信息，并导入构造大表的sql文件。

2）开启自动更新统计信息，查看该表的索引和统计信息。

3）执行如下语句，查看优化器选择的执行计划。

4）手动重新收集该表的统计信息，并查看优化器的执行计划。

通过上述测试可以确认：在表的统计信息不准确的情况下，查询优化器可能会选择错误的执行计划，导致查询性能下降。同时，观察到该系统的 'ws_insurance_his_inf' 表，在导入数据时可能已禁用自动更新统计信息，以提高性能。

4、故障解决方案

针对表的统计信息不准确，导致优化器选择错误执行计划的问题，给出如下解决方案：

1）手动收集表的统计信息

当迁移大表或导入大量数据后，建议先查看该表的统计信息。如果发现统计信息不准确，可以使用以下命令手动收集表的统计信息，确保表的统计信息是最新的，有助于查询优化器生成更准确的执行计划。

命令：analyze tabel schema_name.table_name;

2）定期检查大表统计信息

每日在业务低谷期检查并确认大表的统计信息是否精确，如果不精确则触发手动收集统计信息操作，后续将提供该检查项的脚本。