请问在分区表做 ddl 时，tikv 到 tiflash 同步非常慢，要将近一分钟的时间，最诡异的是这张表在 information_schema.TIFLASH_REPLICA 并不存在 （也就是说没有加入到 tiflash 里面）,这是为啥
ALTER TABLE xxx TRUNCATE PARTITION p20250218
这个是怎么感知到的？
业务在开启前会做 truncate partition 这个动作，在这步会超时退出，结合日志看相关表有 ddl，tiflash 里面也有相应的 Applying partition changes ，感觉要么是 truncate 时间长，要么就是同步到 schema version 在 tiflash 同步时慢（虽然没有加到 tiflash 中）
业务在开启前会做 truncate partition 这个动作 是指什么：
- 创建 a 表，truncate a 表
- alter table a set tiflash replica？
还是说 a 表本身就配置过 tiflash replica，只是每次用 truncate 一次。
因为如果 a 表 tiflash 副本如果本身有，truncate 的话其实会保留属性。分区也是一个道理的。
然后 这步会超时退出 是指什么？是指 ddl 1 min 执行不完么？
- 不创建 a 表，直接 truncate a 表的当天的 partition，在这步会有超时的现象
- 表没有在 tiflash replica 中，但从后台日志看，在做完了 truncate partition ，tiflash 也是做了 Applying partition changes 的动作
我总体感觉下来是 truncate partition 这步卡主了，业务侧超时
看起来意思就是，a 表没有 tiflash 副本，truncate a 表的时候会发现 tiflash 做了相关 Applying partition changes 的操作的动作？怀疑 tiflash 可能影响 ddl 了。我确认下 tidb 是否有这个行为。
然后超时现象啥意思，因为我理解我们 ddl 是没有超时这个说法的。
在没有 tiflash 副本的分区表上执行 truncate partition 的 DDL 以及完成，并不会涉及到与 tiflash 的交互。不过 tiflash 仍然会根据 SchemaDiff 从 tikv 拉最近的 schema 变更，并且自己记录下 table_id 与 database_id 之间的映射关系。这样如果表在之后创建 tiflash 副本时，TiFlash 进程才可以据此拉取到具体的表结构等信息。
看到TiFlash 的日志进行 trucate partition 与 tidb 执行 truncate partition 延迟近 1 分钟，是因为在读/写不涉及到 TiFlash 更新 Schema 的情况下，由每分钟运行一次的定时任务去拉取 SchemaDiff 并更新到 tiflash 中。如果在读/写时，TiFlash 发现需要更新自身进程中的 Schema 副本，就会主动去拉取 SchemaDiff。
1 个赞
如果在分区表不带 tiflash 副本的情况下，执行 truncate partition，这个 DDL 的执行过程与 tiflash 是没有交互的。tiflash 上的行为不影响 truncate partition 的执行耗时。
如果在分区表带有 tiflash 副本的情况下，执行 truncate partition，则 tidb 会等待新的 partition 对应的 tiflash region peer 被成功建立起来后才返回。这是因为 tidb 目前的 tiflash 副本是否可以被访问 (tiflash_replica 中的 available 字段) 是以整个分区表为单位的，不会存在部分分区 tiflash 副本可用，部分分区 tiflash 不可用的情况。
这个情况下，正常 tiflash 上的空 Region peer 也是很快就能建立好的。但如果有其他因素，比如 PD 调度 Region peer 比较缓慢等问题，则可能会影响 truncate partition 的执行耗时。
如果设计上不影响，我理解看下 ddl 为啥慢🤔。
可以先看下 admin show ddl jobs; 内容不。(或者看一下 information_schema.DDL_JOBS 表中内容)