sync-diff-inspector 执行SHOW STATS_BUCKETS WHERE db_name= ? AND table_name= ?耗时7小时

🪐 TiDB 技术问题
,
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.0
【复现路径】MySQL到TiDB迁移，合库迁移场景，将多个MySQL中数据迁移到同一个TiDB实例中，迁移正常。迁移到TiDB中的表数量巨大，将近90万张，但每张表数据比较少，大部分是空表。在使用sync-diff-inspector校验过程中，耗时过长。
【遇到的问题：问题现象及影响】
在使用sync-diff-inspector校验过程中，会自动执行SHOW STATS_BUCKETS WHERE db_name= ? AND table_name= ?; 获取统计信息，但该语句执行非常缓慢，最长耗时7小时，导致无法正常使用该工具进行校验。
【资源配置】配置比较高，CPU、内存均未打满。
【附件：截图/日志/监控】
慢日志：

v6NWw1uJLx
v6NWw1uJLx1341×422 99.9 KB

SHOW PROCESSLIST：
A8Zo13B4po
A8Zo13B4po1331×331 84.3 KB

2
  1. 建议可以先检查一下 slowlog 看看当时 synce-diff 在运行中的慢 SQL ，分析一下当时慢的情况。
  2. chunk-size = 调整到 20万~ 50万，再试一下。 （注意 CPU 的使用情况）
3

迁移完数据后，使用sync-diff-inspector校验数据问题请教 这个贴子的主题看上去和你遇到的情况差不多，你可以参考一下~

4

好的，感谢~。通过show processlist可以查看到正在运行中的慢SQL，都是SHOW STATS_BUCKET语句，slowlog中记录的是已经执行完成的。

目前，通过KILL TIDB强制中断正在运行中的慢SQL，可以解决该问题。但是执行KILL之后，连接并不会马上被杀死，需要等很久，这主要是因为什么呢？

5

在 tidb 执行 SHOW STATS_BUCKETS 也很慢吗？ 是不是统计信息太多了？

6

很慢，如何查看是不是统计信息太多了呢？该怎么处理呢

7
  1. 根据您的描述"表数据巨大，将近90万张", 应该是表太多了。从而桶的信息会更多。请问有看到当前共有多少桶数据吗？
    https://docs.pingcap.com/zh/tidb/stable/statistics#直方图桶的信息。
  2. 在 proceslist 中看到的 db_name and table_name 是一直在变化的吗？ 还是卡在某张表？
    image
    image1100×188 30.4 KB
8
  1. 通过查看mysql.stats_buckets表看到总行数是： 207356
    image
  2. 当前的现象中show processlist并没有show status_buckets where …
    image
    image924×205 6.95 KB

    看日志是卡在这里就不更新了
    image
    image1323×104 8.87 KB