done

效果相当明显。 [img_v3_02pv_6981d2aa-904f-420e-adbd-2e372553615g]

v4.x、v5.x的版本我都测试过，可以正常选择走范围查询，只有v7.x上，默认就走全表扫。线上已经多次SQL走错索引导致应用抖动，遇到了只能通过SPM进行绑定。 当前集群中，只有一个集群有tiflash，还在灰度阶段。

刷新了，也没用。

总结一下该问题： 1、v7.x.x版本，如果全量数据通过BR、lightning、DTS导入到新集群，使用insert into on duplicate key update语句回流增量数据，需要重启tidb server 2、v4.x.x版本，全量数据通过BR、lightning、DTS导入到新集群，使用insert into on duplicate key update语句回流增量数据，无需重启tidb server 3、MySQL5.7版本，使用insert into on duplicate key update语句回流增量数据无异常。

通过重启tidb server，可以解决该问题。 1、将旧集群数据通过BR、lightning、DTS导入到新集群。 2、重启tidb server节点。 3、用dataworks回流增量数据。

相同的数据，相同的表结构，一样的回放流程，在tidb 4.0.11版本与MySQL5.7版本没有出现该问题。

表中的id是自增的，dataworks回流任务里忽略了id，不会将id回流到集群。 [image]

数据存在，不应该是更新嘛。

调整一下顺序就可以了

如果PD Leader节点的网络与其他follow节点通讯异常，岂不是也不会出现故障切换？？

这个变量用于指定 GC 在Resolve Locks（清理锁）步骤中线程的数量。默认值 -1 表示由 TiDB 自主判断运行 GC 要使用的线程的数量。 这个参数还是默认保持不变吧。

改了也不行 [image]

v7.5.6强制绑定索引 [image]

tikv_stderr.log (12.5 MB) tikv.log (12.6 MB)

使用容量较大的本地盘，如果region大小不调整，会导致单节点region个数过多，心跳检测造成资源损耗。

是的，可以看tikv节点的conf目录下的tikv.toml文件，也可以通过tiup cluster show-config查看。有没有通过命令的方式，而不是查看物理文件。

[gggggg] [fffffff] [eeeeee] [dddddddd] [ccccccc]