ob v4.2.1 truncate table (特别慢，表是普通表）

建议与反馈 产品缺陷反馈
#1

想测试这个问题，你们这样去做，弄一个存储过程，反复往这张表里 插入数据，又反复truncate 这这张表。过段时间之后，你会发现。truncate 这张表越来越慢。问题回复现

#3

刚开始我以为是我的开发工具问题，然后我用odc开发工具，truncate table 也是同一慢，有时慢的更离谱

空表02
空表021226×138 27.2 KB

空表
空表1230×525 64.3 KB

空表03
空表031278×603 162 KB

#4

这类问题首先要发集群和租户的资源。可以在 ocp 里查看 集群的 [资源管理] 页面
类似下面这种

image
image772×916 40.7 KB

#5

truncate是ddl操作，请问该问题是发生在数据库长期使用后还是进行测试时候导致的

#6

如果truncate包含在存储过程使用 可能会有存储过程失效重新编译的问题 导致的truncate删除慢的问题
truncate删除表的时候 schema要刷新的

    • schema 刷新需要读取 __all_table_history/__all_part_history/__all_sub_part_history，刷新时间与历史表中的记录数正相关，所以有时候会有些慢的，况且你一直操作， schema 历史信息也是要回收的。
#7

这是创建 表语

CREATE TABLE stat_gg_user_tmp (
id int(11) NOT NULL AUTO_INCREMENT,
uid int(11) NOT NULL,
ggId int(11) NOT NULL,
regTime datetime DEFAULT NULL COMMENT ,
ggTime datetime DEFAULT NULL COMMENT ,
udid varchar(64) DEFAULT NULL,
imei varchar(64) DEFAULT NULL,
cid varchar(200) DEFAULT NULL,
ip varchar(64) DEFAULT NULL COMMENT ,
deviceId varchar(64) DEFAULT NULL COMMENT ,
sysType int(11) DEFAULT NULL COMMENT ,
PRIMARY KEY (id),
KEY cid (cid) BLOCK_SIZE 16384 LOCAL,
KEY ggId (ggId) BLOCK_SIZE 16384 LOCAL,
KEY ggId_uid (ggId, uid) BLOCK_SIZE 16384 LOCAL,
KEY ggTime (ggTime) BLOCK_SIZE 16384 LOCAL,
KEY uid (uid) BLOCK_SIZE 16384 LOCAL
) AUTO_INCREMENT = 1 AUTO_INCREMENT_MODE = ‘ORDER’ DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = ‘zstd_1.3.8’ REPLICA_NUM = 2 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0 COMMENT = ‘test’

#8

数据库是线上阿里云的，一个存储过程，里面有truncate tmp_table && select * from xxx_table insert into tmp_table; 每次都是 在truncate tmp_table耗时特长，有时导致 后面语句都还没执行，定时任务 每10分钟 调用这个 存储过程

#9

有可能是内存使用太高，转储导致的
查看下freeze_trigger_percentage参数的大小
下面是转储sql，试试转储后truncate还慢么
ALTER SYSTEM MINOR FREEZE TENANT= prod_tenant;

#10

你好 请问测试出效果了么