MySQL 模式 Truncate/Drop 分区操作耗时很长的原因

本文主要说明在指定 DDL 针对分区表进行 Truncate 或者 Drop 分区动作耗时长(可能数小时或者超时)的现象。

Truncate/Drop 分区耗时长说明

obclient > alter table drop partition xxx;

分区表如果包含全局索引，那么删除分区后，OceanBase 数据库的 MySQL 模式下会自动重建该全局索引。如果数据量很大，重建全局索引是非常耗时的，整个 DDL 的耗时可能会超过预期，甚至超时。

DDL 的超时时间由系统配置项 _ob_ddl_timeout 来控制，默认值为 1000s。

对于分区表，如果经常需要使用 Truncate 分区来清理数据，应尽量避免使用全局索引。

Truncate/Drop 分区的补充说明

目前 drop/truncate 分区的实现方法是：

• MySQL 模式下，会将对应表的所有全局索引进行重建（删除索引后，重新创建索引）。

• Oracle 模式下，默认会将索引置为无效，然后可以通过先 drop index 操作，之后 create index 操作手动重建索引。

  在 drop 分区或者 truncate 分区语句后跟有 update global indexes 子句时, 会像 MySQL 模式那样自动重建索引。

适用版本

OceanBase 数据库 V2x、V3.x 版本。