有机会升级下版本，升到 6.5.9 在试试

这个表的数据变动是不是特别大？ 我观察到，扫描全表，就会扫描的key，和总key数相差不大了… total_process_keys: 34892667, total_keys: 34892770, 看起来 timestamp 是热点索引… 没启到效果 可能你要换种方式来建索引… 要尝试一下

呵呵，删了之后没重建吧

围观下，这个场景主要有什么问题？

除了 L0 level 是 Immutable MemTable 的映射，为了满足顺序写入是无须的，其他的 Level 在 Compaction 合并的时候，会保证有序。 L0 level 比较特殊，因为内存中有相应的数据，检索也会很快

围观发布历史，文档中有很详细的描述，每个小版本都有特性更新和bug修复 例如： https://docs.pingcap.com/zh/tidb/stable/release-7.0.0 https://docs.pingcap.com/zh/tidb/stable/release-7.1.0 有兴趣可以慢慢看

这个表的健康度可以查下，如果表的数据变动比较大，建议手动 analyze table …

参考 TICDC 的配置，CloudCanal 应该有说明的 binlog_format 是兼容配置，用于兼容mysql 的，对 TICDC 无实际意义

实际执行了多久？ 这个也太夸张了，这么少的数据 [image]

先上个集群状态图，不限于 tiup，dashboard 等等 在上个配置清单，补充下信息再看

PD 如果异常，，需要重新设置， PD 是调度中心，PD 切换后调度指令可能会失效 建议观测 tikv 所有节点的 leader 信息是否有变化，若有变化，只需要等待即可。 驱逐节点的速度和效率，取决于集群的配置和性能，也有其他的参数可以加速驱逐。请参考！

可以新增N 个节点，然后在能足够负载处理的情况下，可以拿掉 N 个节点，从这个视角看会比较容易… 整个过程是对服务处理无影响，，

建议从场景学习，要了解端到端的解决过程和目标，光练习技术，缺少相应的价值点，会容易迷茫 不过，tidb 的技术体系太过于庞大，还是老老实实从最基础的课程开始学吧，一点点的精进… 不然，场景说了的问题和目标，也不会太明白是怎么解决的…

truncate table 会更快了 drop 是连表都删掉了，不一样的…

dm 组件有部署么？上传 DM 服务的状态情况看看 [image]

gc or compact 的操作是针对 tikv 的… 然后不论 是 GC，还是 compact 都会占用 tikv 的资源 至于大事务的问题，也应该考虑进去… 这玩意会吃很多内存… 新版本对大事务好像有一些优化，能够分批执行，我忘记哪个版本了

很简单啊，delete SQL会作用到 tikv，ticdc 会捕获 tikv 数据变动的事件 如果 delete row 特别多，比如 50W 行，比较常见了 那ticdc 也会回放 50W 行event到下游， 这个时候会出现两个问题： ticdc changefeed 设定的资源是否足够处理这个量级 ticdc 下游对接的服务，是否有足够的资源处理这个量级 ok，处理不了，ticdc 就会 delay 了…

写错了，7.1.5， 大版本有一些变化的（主要是新特性，肯定会有一些影响了），小版本都是修复bug为主了

tidb 的 DDL 是动态的切换过程，需要让子弹飞一会… 除非确定 DDL 的 operation 被 lock了，或者 Dead，没到下一步 有两种办法： DM手动操作跳过这个 DDL 步骤 DDL Job 手动Stop，在找空闲的时间，手工的处理这个 DDL 的过程 7.1.0 有些小bug，建议升级到 最新的小版本，7.5.1…