结论等待中
PRIMARY KEY ( c_w_id , c_d_id , c_id ) 组合主键现在的分段方式，导致 tidb 执行计划需要用全表扫描。
如果要提升速度，可以把 chunk-size = 1000 调大，mysql 会变慢，tidb 因为函数可下推速度较快，大概调整到 20万~ 50万，处于 mysql 和 tidb 两者的平衡点，整体速度会提升。
那个已经是1000了:joy:
对了，顺便问一下，跑diff的时候，对集群的影响大不大？比如diff的CPU，IO，内存等，对集群的影响如何？
- 楼上的意思是由于看之前的执行计划，tidb 这边走的是 table_full_scan 的算子。所以调大 chunk-size 其实是可以减少 chunk 的数量来减少匹配的时间。不过这块也会对上游的 MySQL 有影响。这块需要注意一下。
- CPU 、IO 、内存 都会受到 chunk-size 以及 check-thread-count 的影响。一次匹配的数量越多，上下游的查询的数量以及计算 checksum 的消耗就越高。
额，
1、我每次跑diff的时候都是设置的chunk-size=1000，感觉好像没有绕过 table_full_scan。。。
2、diff会占用一定的CPU、IO、内存等，这个线上的话，没有那么长的时间窗口给我们验证一致性，所以除了这个参数还有没有什么参数或者方法可以提升diff速度，最好还是在规定窗口中diff完。
check-thread-count 设置了多少。能否调大到 cpu_cnt * 0.8
或者在考虑一下 sample-percent 是不是要 100% 全部检查。
1、check-thread-count：好像设置了全部的cpu线程数
2、毕竟是线上环境的数据全部导入，如果能够全部扫，最好还是全部扫吧。对了，请教一下，如果不是全部扫的话，那么你们这里推荐设置未多少，才比较可信呢？
chunk-size = 1000 调大，调整到 20万~ 50万，再试一下。
对集群影响大不大这种，建议您可以直接使用 dstat 看一下。
一个命令是可以拿到所有结果的。看一下对性能的影响是否满足您这面的需求。
另外，我们建议 100% 抽样。但您这面可以根据您的业务进行适当的调整。
这个跑diff的那台机器上CPU一直在跳动有的时候能跳到90%多
好的，我找个时间试一下
辛苦测试后，继续反馈下信息，多谢。
好的。集群现在有人在用，他们不用的时候或者周六周日找个时间测试一下，然后同步一下情况。
你好，谢谢，我这次使用了2G左右的数据测试了一下，当chunk-size设置为1000时，校验花了1h26m14左右，当我将chunk-size设置为300000时，校验花了57.6秒左右，时间得到了提升，这个通过提升每一块的大小从而减少了chunk的数量，减少匹配次数，提升速度了，是吧，我在diff的时候，看了一下，执行匹配的两个数据库的节点上CPU达到了90%多，这个设置chunk-size值变大，提升了速度，牺牲了哪些性能呢？
加大 chunk-size 主要消耗的是计算资源，CPU 的 workload 会变高。
哦，好的，CPU我看到了，还有其他的嘛？比如mysql所在在的节点的IO等
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。