看看这个帖子
8kw插入1个小时，能不能优化搞成分批啊
看上去是由于insert into的job长时间锁住了表，导致truncate的ddl job执行失败。truncate能加time wait超时参数吗？
嗯 帖子中的方式三 ，验证可以释放阻塞，最近被阻塞的太频繁，经常重启影响太大。
想 尝试方案二 - - SELECT concat('kill ',session_id,';') FROM mysql.tidb_mdl_view order by TxnStart
读取这个表，查询很慢，一直读不出数据。
不是同一张表
insert 的表 ，和truncate 的阻塞表，不是同一张表。最近三天观察，都是这个时间发生阻塞情况
上次我们也是因为元数据锁的原因导致ddl被阻塞了，就是按照博文的内容处理的
重启TiDB Server 方式释放 阻塞任务？
是因为truncate table的表太大了吗？tidb没有办法像mysql那样做硬链删除，可以先做改名处理吗
不是因为 truncate table 表太大了哦，不管大小，truncate 语句做的是一样的，它这个应该是元数据锁相关问题
应该看看卡住的时候，DDL执行队列里有哪些在执行，哪些是等待执行的
日志里有有用的消息吗？你是什么版本，较新的版本dashboard有一个日志搜索的功能
元数据锁导致的问题，建议关闭该功能。
查到对应时间点的 日志显示大量的 rollbackTxn called due to ddl/autocommit failure 错误
没有搜索到 帖子中的 old running transaction block DDL  的错误
在重启释放 阻塞任务，关闭元数据锁，有什么影响？ 看看明天是否还会有阻塞，如果还存在，连续4天发生阻塞，要尝试关闭元数据锁了
如果业务有重试机制，就没啥影响。具体可以仔细看看我之前整理的这篇文章：
在 TiDB 中对表元数据对象的更改，采用的是 Online DDL 在线异步变更算法。SQL 语句在执行时会获取开始时对应的元数据快照，如果事务执行过程中所涉及的表上发生了元数据的更改，为了保证数据的一致性，之前的 TiDB 会返回 Information schema is changed 的错误，导致用户事务提交失败，用户体验不好。
所以官方为了解决这个问题，在 TiDB v6.3.0 中，online DDL 算法中引入了元数据锁特性。通过协调表元数据变更过程中 DML 语句和 DDL 语句的优先级，让执行中的 DDL 语句等待持有旧版本元数据的 DML 语句提交，尽可能避免 DML 语句报Information schema is changed 的错误而执行失败。
在 v6.5.0 及之后的版本中，TiDB 默认开启元数据锁。当集群从 v6.5.0 之前的版本升级到 v6.5.0 及之后的版本时，TiDB 会自动开启元数据锁功能。如果要关闭元数据锁，可以将系统变量 tidb_enable_metadata_lock 设置为 OFF。
应该是 8kw 这个表的 执行Truncate & insert 数据，引起其它表的 DDL 阻塞。今天禁用了这个表的任务执行，没有在出现DDL 阻塞的情况
长知识了