ob为啥Truncate table为临时表的时候，是delete操作，而不是DDL行为
这个是基于什么考虑的？
1 个赞
在4.x之前的版本，truncate table是通过DDL事务内原子地drop & create table来实现。由于truncate table涉及table_id（partition_key）的变化，除了完成partition的操作外，该过程需要根据旧表schema，重建新表的index、foreign key、audit、obj privilege、trigger等其他schema信息。可知，table对象越复杂，truncate table涉及的SQL数目就越多。在4.x版本，truncate table采用替换tablet的方式实现，由于不涉及table_id的变化，极大地简化了truncate table的实现及减少该过程由于重建schema而产生的SQL。
谢谢老师回复。
还有个疑问，OB上实际操作TRUNCATE表的时候（表数据量千万级），普通表非常快，但是临时表非常慢；这种普通表和临时表是有什么差异嘛？
什么版本的OB，是不是临时表数量很多。可以去sys租户下查一下__all_table_history表数据量是不是非常大。临时表的trucate操作会需要更新schema version, truncate table过程会尝试等30s schema刷新成功再返回，如果多次等不到的话会导致耗时长。
OB版本是4.2.2
系统临时表数量差不多有1000个
sys租户下查oceanbase.__all_table_history这表里边的数据有多少
oceanbase.__all_table_history数量是2765
看起来临时表和oceanbase.__all_table_history数据量也不是太多。再多问一句，集群配置啥样的，还有就是Truncate table临时表耗时多久。
集群 X86_64 CPU 80核 内存 380G 磁盘（SSD）
租户是6核20G内存
Truncate 500W的临时表耗时大概需要500多秒；清空临时表后，再次TRUNCATE需要6秒左右
Truncate 500W的临时表的时候用obdiag analyze log --since 15m 分析一下最近15分钟的日志看看有没有问题。obdiag 安装使用文档：OceanBase分布式数据库-海量数据 笔笔算数
他应该想问得是这个问题：
临时表清理为什么会慢
https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000466054?back=kb
1 个赞