一次数据库查询缓慢故障复盘：大表数据增长、SQL全表扫描导致系统响应异常

XX系统数据库查询缓慢故障复盘记录

一、故障概述

故障时间： 2026-10-01 上午

影响系统： XX系统

故障现象：

用户通过Web端进行业务查询时，出现：

页面长时间加载；
查询结果无法及时返回；
用户感觉系统响应缓慢。

经数据库侧排查，确认数据库服务正常运行，主从复制状态正常，故障原因为业务数据量增长及SQL执行效率问题导致数据库查询性能下降。

二、故障现象

用户执行业务查询时，Web页面无明显响应。

数据库侧观察发现：

相关业务表数据量较大；
查询SQL执行时间较长；
查询过程中存在大量数据扫描。

同时，开发人员执行历史数据清理操作：

复制代码

DELETE FROM xxx WHERE xxx;

由于删除数据量较大，执行时间较长。

在删除操作执行期间，仍有用户持续进行业务查询，导致数据库资源竞争，最终造成查询响应缓慢。

三、故障涉及数据表

本次问题主要涉及XX系统流程相关业务表：

表名	数据规模
flow_ru_task_ext	大量历史流程扩展数据
flow_ru_task	流程任务数据
flow_ru_task_his	历史流程任务数据
flow_ru_node	流程节点数据
flow_ru_form_data_value	表单字段数据
flow_ru_form_data	表单数据
flow_ru_form_data_value_his	历史表单字段数据
flow_ru_form_data_his	历史表单数据
flow_ru_instance	流程实例数据

其中较大表：

flow_ru_task_his

数据量：

约4162万行
表大小：

约16GB

已有索引：

复制代码

PRIMARY(task_id)

approver

instance_id

task_status

create_timestamp

flow_ru_form_data_value

数据量：

约2280万行
表大小：

约5GB

长期未进行有效的数据清理及归档，导致业务历史数据持续增长。

四、故障定位分析

1. 数据量持续增长导致查询压力增加

通过数据库表容量分析发现：

部分业务历史表长期累积大量数据。

随着数据规模不断增加：

表数据页增加；
查询扫描范围扩大；
SQL执行成本升高。

原本正常运行的查询，在数据量增长后逐渐出现性能下降。

2. 查询SQL存在全表扫描问题

Web端业务查询涉及多个大数据量业务表。

由于：

查询条件未能有效利用索引；
SQL过滤条件不足；
历史数据未及时归档；

导致SQL执行过程中出现：

复制代码

Full Table Scan（全表扫描）

数据库需要扫描大量数据后才能返回结果。

当数据量达到千万级甚至更高时，全表扫描会明显影响查询效率。

3. 大批量DELETE操作进一步加剧数据库压力

为减少历史数据量，执行历史数据清理操作。

但是由于删除数据量较大：

DELETE执行时间较长。

大批量DELETE会产生：

大量Undo日志；
大量Redo日志；
数据页修改；
索引维护；
长事务。

同时：

用户查询请求仍然持续执行。

数据库同时处理：

复制代码

大批量DELETE事务
        +
大表查询扫描

导致数据库资源竞争：

IO压力增加；
Buffer Pool缓存竞争；
SQL响应时间增加。

最终表现为：

复制代码

Web端查询无响应

五、故障根本原因

本次故障根本原因：

XX系统历史业务数据长期增长，相关业务表缺少有效的数据生命周期管理机制；同时部分业务查询SQL未针对大数据量场景进行优化，导致查询过程中出现全表扫描。在执行大批量历史数据删除操作期间，与用户正常查询请求产生资源竞争，最终导致系统查询响应缓慢。

六、经验总结

1. SQL设计合理性的重要性

本次故障最大的经验：

数据库性能问题不一定是数据库服务器资源不足，很多情况下根本原因在于SQL设计及数据访问方式是否合理。

同一条SQL：

小数据量阶段：

复制代码

少量数据扫描
快速返回

随着数据增长：

复制代码

数据量增加
↓
扫描范围扩大
↓
执行时间增加
↓
影响业务响应

因此SQL设计需要结合未来业务数据增长规模进行规划。

2. 数据生命周期管理的重要性

对于流程、日志、历史记录类业务表：

不能无限增长。

建议建立：

数据保留周期；
自动清理机制；
历史数据归档；
大表增长监控。

3. 大批量数据删除风险

生产环境避免一次性执行大量DELETE。

建议：

分批删除

例如：

复制代码

DELETE FROM table
WHERE id < xxx
LIMIT 10000;

循环执行。

降低：

单次事务大小；
Undo压力；
锁持有时间；
对业务查询影响。

七、整改建议

短期优化

对历史数据进行分批清理；
清理前评估影响范围；
避免业务高峰执行；
持续观察慢SQL情况。

长期优化

建立历史数据归档机制；

例如：

复制代码

业务历史表
      |
      ↓
历史归档表

减少在线业务表数据规模。

优化查询SQL：

重点检查：

WHERE条件；
JOIN关联字段；
ORDER BY字段；
分页方式；
索引匹配情况。

建立数据库性能监控：

包括：

大表排行；
数据增长趋势；
慢SQL分析；
索引使用情况。

八、总结

本次故障属于典型的数据库性能问题案例。

故障并非由于数据库服务器故障，而是由于：

业务数据长期增长 + SQL全表扫描 + 大批量删除操作并发执行

共同导致数据库查询性能下降。

通过本次问题排查，进一步认识到：

数据库稳定运行不仅依赖硬件资源和数据库自身状态，更依赖合理的数据管理策略、SQL设计能力以及业务系统长期规划。

在生产环境中，需要同时关注：

数据规模变化；
SQL执行效率；
数据生命周期管理；
大批量操作风险。

只有数据库、应用和业务设计共同优化，才能保证系统长期稳定运行。