数据库 TRUNCATE 操作执行耗时异常偏高及 __all_table_stat 系统表锁等待问题诊断与优化指南

问题现象

在执行 TRUNCATE TABLE 操作时，耗时异常偏高。通过 SQL Audit 追踪发现，内部 SQL DELETE FROM __all_table_stat WHERE tenant_id = ? AND table_id = ? 持续报错 -6005（锁冲突）并处于等待状态。

排查发现：

• RS 日志中未发现其他串行 DDL 阻塞。
• 三个 transfer 视图均无相关记录，可排除数据迁移干扰。

问题原因

OceanBase 数据库中，TRUNCATE 表操作与统计信息收集任务并发时，因内部元数据表锁竞争导致 TRUNCATE 执行缓慢。

具体原因如下：

• 执行 TRUNCATE 表操作时，底层会触发一条删除内部系统表 __all_table_stat 对应记录的 Inner SQL（例如 DELETE FROM __all_table_stat WHERE tenant_id = ? AND table_id = ?）。
• 当该操作与长时间运行的统计信息收集任务并发执行时，统计信息收集进程会对 __all_table_stat 表持有锁。
• 此时 TRUNCATE 操作的内部删除请求会与统计信息收集的锁产生冲突（返回错误码 -6005），导致 TRUNCATE 操作进入锁等待状态。

该场景下的典型表现是 TRUNCATE 耗时显著增加（通常达数百秒），这是由于内部元数据表的并发访问控制机制造成的。只有当统计信息收集任务执行完毕并释放锁后，TRUNCATE 的删除请求才能成功执行，从而完成整个 TRUNCATE 流程。

关键信息

• 核心报错：内部 SQL DELETE FROM __all_table_stat WHERE tenant_id = ? AND table_id = ? 持续返回 -6005 错误码。
• 诊断路径：
  1. 通过 SQL Audit 定位阻塞 TRUNCATE 的底层内部 SQL 及锁等待链。
  2. 结合 RS 日志与 transfer 视图快速排除串行 DDL 或数据迁移干扰，精准锁定统计信息收集进程。

问题的风险及影响

导致 TRUNCATE 操作耗时显著延长（可达数百秒），影响业务 DDL 执行效率及整体运维体验。

适用版本

OceanBase 4.x

解决方法

1. 应急处理：主动终止当前正在执行的统计信息收集任务，释放锁后 TRUNCATE 操作将立即完成。
2. 调度优化：在集群配置或运维计划中，合理错开统计信息收集窗口与批量 DDL 操作时间。

规避方式

1. 避免在统计信息收集期间执行 TRUNCATE 操作。
2. 若业务强依赖 TRUNCATE，可提前关闭当前租户或目标表的统计信息自动收集功能，待操作完成后再重新开启。
3. 触发条件提示：长时间运行的统计信息收集任务与 TRUNCATE 操作并发时易引发此现象，日常巡检中需注意此类并发场景。