【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】
服务器使用的是4T的机械硬盘，在清洗数据过程中，清空中间表，每个大约几M到十几M,耗费时间在 100秒以上。数据库所有参数均为默认 。不知道是否有优化空间，提升清空表速度。
【遇到的问题：问题现象及影响】
在清洗数据过程中对中间表进行truncate操作，一个几M的表truncate操作大概需要100秒。
【资源配置】
【附件：截图/日志/监控】
问题发生在夜间2点到2点半之间。
问题发生在夜间2点到2点半之间。
1 个赞
truncate 这么耗IO？按理逻辑 ddl 只修改元数据，不应该用这么多IO，即使是机械盘
先分析，看耗时在什么地方
mysql> show profiles;
找到对应的 Query_ID
mysql> show profile for query 1;
看看duration最大的status是啥
看看是不是有元数据库锁，上次碰到一次，
当时的情况是清洗数据，不存在其它类似 修改表，建索引等，就是批量的中间表需要清空。然后同时有大量的数据查询，统计。
DDL job 队列中基本上都是create table 和truncate table 任务
建议还是用SSD盘，曾经遇到过某云下的机械盘安装MySQL，光是启动就要十分钟，后面换成SSD后秒起。
1 个赞
正常机械盘也不应该这么慢，发问题时段 TiDB 日志看下，每个节点都要
一开始清空表时300多毫秒，后来有多有少，再后来就持续性上涨。一直居高不下
热表可能会truncate耗时的，mysql中遇到过
DDL job 队列排队很久吗
这个目前不清楚，是凌晨自动跑的任务 。
自动跑的是同步还是异步的？异步的会不会造成并行执行或者积压？
同步 ，多线程
有可能是清理任务有堆积，之前我们并行清理分区表生命周期之外的分区时就出现了任务堆积
每天都这样么？这个好像没办法同步执行，因为gc是异步操作的。日终操作，是否可以改成单线程？
可能是元数据锁造成的等待