alter table drop/add partition 操作耗长问题

问题描述

在 OceanBase 数据库中，当针对分区表执行添加或删除分区的 DDL（数据定义语言）操作时，可能会出现耗时长（可能数小时甚至超时）的情况。

适用版本

OceanBase 数据库 V2.x 和 V3.x 版本。

问题原因

该问题是默认行为。如果分区表包含全局索引，在执行删除分区操作后，OceanBase 在 MySQL 兼容模式下会自动重建该全局索引。对于分区多、数据量大的场景，重建全局索引是非常耗时的，因此整个 DDL 动作耗时超过预期时间，甚至可能超时。

解决方法

• 分区表如果需要定期清理，建议使用 Local 索引来代替全局索引。

• 如果分区表存在全局索引，考虑替换为 Local 索引。如果无法替换，可以在业务低峰期执行 alter table drop/add partition 操作，并同时调大超时时间。

更多信息

drop/truncate 分区操作会减少表的内容。如果表上存在全局索引，这些索引数据会变得无效，需要重建。目前 OceanBase 数据库对 drop/truncate 分区的实现方式是：

• 在 MySQL 模式下，会自动重建表的所有全局索引（删除索引后重新创建索引）。

• 在 Oracle 模式下，默认会将索引置为无效（可以通过 drop index/create index 手动重建索引）。在 drop/truncate 分区语句后跟有 update global indexes 子句时，会自动重建索引，类似于 MySQL 模式的行为。

由于 drop/truncate 分区操作可能导致索引的重建（删除后重新创建），这个过程耗时较长且资源占用较高（包括内存和磁盘）。在使用时，建议进行以下限制：

• 被 drop/truncate 分区的表上的索引不宜超过 5 个。

• 在涉及索引重建的 drop/truncate 分区操作时，尽量避免并发操作，或者并发创建索引。

• 在涉及索引重建的 drop/truncate 分区操作时，数据表和其索引表的分区数不宜超过 100 个。

• 在主备库最大保护模式下，涉及索引重建的 drop/truncate 分区操作完成后，才能对该数据表进行写入操作。