infomation_schema.partitions记录过多导致Too many partitions (including subpartitions) were defined

OceanBase
,
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】3.1.4
【问题描述】在创建新表时，出现Too many partitions (including subpartitions) were defined报错，经过后续排查，发现时infomation_schema.partitions记录过多。和预想不太一致的是，在OceanBase中没有分区的表也会在partitions中存在一条记录，只不过分区字段都为空。目前partitions表中有30多万的记录数量，其中table_name为delay_delete开头的占绝大多数。目前猜测可能是由于大量创建临时表，然后对表进行DROP导致，但是在OceanBase中，过期的partition记录并没有被自动删除。有几个问题想问一下

  1. partitions表中的记录需要手动删除吗？是否可以直接删除相关无效记录
  2. 此问题是什么原因导致的
  3. 能够支持自动清理失效的partitions记录
  4. 数据库变慢与此是否有影响
    【问题现象及影响】
    导致目前无法创建新的表，整个数据库处理速度缓慢

【附件】

#3

你的问题我们已经收到，稍后会有相关人员回复

#4

1.问题产生的原因 是租户分区数达到了上限 一般建议 单表分区个数限制

MySQL 模式：8192 个
建议删除空闲分区 或者增大租户内存
2.默认情况表被drop后,分区记录会被垃圾回收(3.1.4版本至少要等待30分钟)
3.如果长时间分区记录无法gc,建议参考
先记录待操作（Drop、Truncate）表的table_id
select table_id from __all_virtual_table where table_name = ‘xxx’;

执行命令
drop table xxx; 或者 truncate table xxxx;

一定要确保执行purge recyclebin操作，否则GC无法执行；
purge recyclebin;

等一段时间，查询虚拟表，确认这些分区都已经删除完成：
select count(1) from __all_virtual_pg_partition_info where table_id=xxx;

4.分区数增多,对系统会产生额外的开销,因此和当前数据库变慢有影响,但无法保证是导致数据库变慢的根本原因

1 个赞
#5

为啥增加租户内存，就可以扩充分区数限制哪？

#6

因为分区越多，就需要维护更多的源数据和索引信息，这些会占用内存

#7

在测试过程中，一晚上生成了50万的临时表，但是partition表中的记录只被清理了20万，仍有大量分区未被处理，处理速度较慢，这个处理速度正常吗，这个速度与数据库配置有关吗