【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】
数据迁移truncate DDL执行时间晚于INSERT 的DML操作导致迁移结果不一致
【遇到的问题：问题现象及影响】
数据迁移，软件的逻辑是先执行truncate table，然后把全量数据load data进去表里面。结果truncate 语句执行晚于LOAD DATA，最终导致结果是源表700多条数据全部为空！！
我当时看到TIDB居然把DDL和DML分开我就觉得这个设计很诡异，没想到真的被我踩坑了。
希望产品设计不要拍脑袋就干。想一下实际场景。如果认为我这个说法不对的，请讲一下当初的为什么要这样设计~
当然，我感觉也有解决办法，就是同一个session，同一个表应该进行排队，先到先做！
另外一种办法是，请不要把TRUNCATE 当DDL处理好么？
确定是串行执行的，TRUNCATE没有执行完就开始执行加载数据了吗
TiDB 中的 TRUNCATE 是 DDL（Data Definition Language，数据定义语言），这一点与 MySQL 中的 TRUNCATE 类似。
truncate操作是同步操作。你不等truncate执行完就另外session执行load data，本身自己程序逻辑就存在问题吧。
1 个赞
先load再truncate 然后表空了，这不正常吗？ 6.5已经有mdl锁了，事务阻塞ddl。第一次听说dml队列，这是哪里看到的
如果是什么情况下导致truncate未开始执行，应该是会有这种情况
统一回复，确实错怪tidb了。因为软件日志显示数据导入成功，实际上是导入失败！
软件也确实像各位所说，有进行串行排队处理。
前期接触tidb碰到ddl慢的情况，先入为主了。抱歉。
1 个赞
为了不影响tidb的声誉，我想删帖，可以删帖吗？
不用删，这本来就是 TiDB 技术社区，就是让大家来聊 bug 和问题的，你这个是技术探讨
吓一跳。
还以为这有这样低级的bug 
这要是有问题，就是重大Bug了
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。