https://docs.pingcap.com/zh/tidb/stable/three-data-centers-in-two-cities-deployment 设置 PD 的优先级，为了避免出现跨区域 AZ 的 PD 成为 Leader，可以将本区域 AZ 的 PD 优先级调高（数字越大，优先级越高），将跨区域的 PD 优先级调低。 member leader_priority PD-10 5 member leader_priority PD-11 5 member leader_priority PD-12 5 member leader_priority PD-13 5 …

我也不是很清楚，没有找到issue编号。

b站上刷到过一个tapdata从mongodb到MySQL的演示，但我自己没有用过这个。 如果不愿意折腾的话，还是cloudcanal。

select * from INFORMATION_SCHEMA.TIDB_INDEXES 从这个表里面看到主键的名字就是PRIMARY，不过不确定再这个语句中行不行。你可以试试。

我是感觉，应该尝试找找日志有没有统计信息相关的报错。 发现是统计信息的问题，然后删掉统计信息，再重建，这个有点被动。 再不行，有任何主动检测的办法也可以接受。

报错信息build global-level stats failed。 fail to get stats version 5分钟一次，analyze时间长 我是感觉真的需要重视起来了，不能当作偶然了。 单个看都有偶然性，不过在统计信息这个点上，问题是连续出现的。

// FormatForExplain format the content in the format expected to be printed in the execution plan. // case 1: if stats version is 0, print stats:pseudo. // case 2: if stats version is not 0, and there are column/index stats that are not full loaded, // print stats:partial, then print status of 3 …

你的这个db怎么老是遇到这种统计信息的问题。 好几次了。要么是某个分区统计信息收集了以后global的不行，要么是某个字段的统计信息不行。 这类问题我感觉你碰上好几次了。已经到了 不能当作偶然对待的程度了。

[1701941416490] 这意思是说ind_paid_time这个索引只有一部分，所以不能用？

https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices#高并发批量插入场景 可以先尝试照着最佳实践做做看。

这个数字是大的离谱，如果能复现的话，应该算作bug。

sudo: a password is required sudo免密加一下看看？

版本有点太老了。关键是tidb如果没有办法升级，光升dm也不太行。所以在不升级的情况下，也只能是想办法跳过了。

从dm到tidb都升到7.5了。

用dm exec tiup dm exec [dm-cluster] --command=‘pwd’ -R dm-worker 试试上面这个。可以在dm-worker上统一执行pwd命令。 换成你要的清理日志的命令就可以了。 最好不要直接原地rm -rf ，可以先统一mv到一个别的地方（比如/bak），然后看过没有问题，再rm -rf /bak/*

Unified Read Pool解决的是长短查询混合场景下，qps下降的问题。 [image] 在analyze的时候，可以视为一个长查询，如果使用Unified Read Pool的情况下，如果造成了qps的猛降，像上面这个文章的里面的图一样是不符合预期的。 然后就是300%也只用了3个核吧。analyze的并发度有其他的参数控制。 https://docs.pingcap.com/zh/tidb/stable/statistics#控制-analyze-并发度 基本都在4到1之间，如果没有特别调整过其中的某几个，我感觉300%是个比较正常的值。

确实挺奇怪的。不过要分析之前为啥没有成功，就需要以前的升级时期的日志了。

[1701769771143] 7.5版本,subpartition的写法是不会报错的。但实际建立的只有分区。没有子分区。

这里的意思是，每秒调用1.4次insert，每次insert 平均耗时25.3ms。 非常正常。就是累计次数多了，总时间就到10s了。