这个变量用于指定 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]

一样的 ±-----------------±--------------+ | Variable_name | Value | ±-----------------±--------------+ | system_time_zone | Asia/Shanghai | | time_zone | SYSTEM | ±-----------------±--------------+

sql_mode全部为空

还在查，目前还没有解决，怀疑是锁的问题导致的。

都已经看过了，这些信息跟5.3.3版本的api接口一致。 但7.1.5版本通过该接口访问直接报认证错误，不知道高版本在哪儿个地方调整过。

通过与军总的沟通，2月份对pd server进行替换后，当时没有去执行 --skip-restart命令。 [image] 先执行tiup cluster reload tidb-xxx --skip-restart后，然后再重启tidb server，问题解决。 [image]

dumpling版本太低，有些参数是没有生效的。

专业，大佬分析的有理有据。

没有其他解决方案，只能升级，会影响5.3相关版本。

该问题是由TiDBbug导致，可升级为5.3.2版本解决。 https://github.com/tikv/tikv/issues/11612

该问题是由TiDB的bug导致，可升级为5.3.2版本解决该问题； https://github.com/tikv/tikv/issues/11612

[F] Auto Analyze QPS始终为0，应该是没有触发； 如果我修改performance.run-auto-analyze:false，是不是可以解决这个问题？ 一直对某张表或者某个索引重复的收集，这是什么原因呢？