毕竟这个截图里，已经有部分 SQL 已经切换到 nmgmy 资源组了。

我也怀疑是长链接的问题，切换资源组后，只对新链接生效

是的，这个可能性最大，因为看你发的执行计划，是已经走到索引了的，所以只能是扫描数据量的问题导致的

顺便问下，TiKV 存储的 IO 效率怎么样？以及查询时候 TiDB 和 TiKV 的负载怎么样？ 瓶颈是在 TiKV 还是 TiDB ?

应该是只有col_6 以及col_2参与查询，会用到覆盖索引不需要回表，所以查询效率很高，而加了 col_18 这些其他字段，走不了覆盖索引，需要回表，所以查询效率变慢了。 你 count(1) 看下总共命中的有多少行？

失败原因倒是找到了，是因为存储问题导致的，但是实际上告警的这台机器是冷数据盘，虽然剩余小于 10%，但实际可用空间还有1T 空间可用，用来加索引绰绰有余。。 ERROR 1105 (HY000): the remaining storage capacity of TiKV(172.18.****:20160) is less than 10%; please increase the storage capacity of TiKV and try again

TiKV 和 TiFlash 并不是割裂必须2选1的，其实可以选择高频高优先级的查询场景，对相应的字段正常加索引，针对低频低优先级的查询场景， 完全可以让走 TiFlash 来硬抗。

TiFlash 是针对 AP 场景的，所以 QPS 确实不会很高。一般都是结合 TiKV 使用，TiKV 用来应对高频的 TP 查询， TiFlash 用来应对低频的 AP 查询。如果既是 AP 查询，又很高频，其实也可以通过堆 TiFlash 机器个数来应对。

TiDB-Runtime 监控里的信息 [image]

还是老架构同步的，上游 TiDB 版本是 7.5.2

tidb-sever-heap.pprof (8.9 MB) 这是其中一台 tidb-server 的heap pprof，不过感觉不太准，这里只有 5 G，实际上是占用了 30G。 [image] [image]

看下 cdc.log 吧，那里会有哪个 SQL 执行报错的信息

如果是通过业务 SQL 更新的数据，那就不是我说的太小的问题，在数据量小的时候更新数据也会造成健康度下降，但是不会触发 analyze，和你的表现还不一样。 感觉你是遇到某些 BUG 了，看下 TiDB 日志里，搜一下 analyze 看是否有对应的错误日志

初始表的健康度都是 100%，只有表数据存在更新时候，表的健康度才会下降。

[image] 这个表是通过 BR 或者 lightning 物理导入后，一直没有修改过么？ 因为 Row_count 在内存里标记没超过 1000，所以并不会主动 analyze

你把配置文件的密码和 IP 信息删掉，贴出来看下？ 感觉是某个地方配置错误了。

得用 convert to 命令，不能直接改表的 default charset，那是不会改现存字段的 collate 的

你用什么命令改的？看下 username 字段的字符集现在是什么？

换个 2.0.4 的 dmctl 来操作试下