单节点混布？发一下服务器配置吧，如果是标配不应该这么差

关键实际存储长度是多少，如果实际存储长度就是这么长，那感觉加索引没什么意义，后期大概率都是like语句，也不会走索引。

不好查，估计只有审计日志里才有。像我们这边都是一个用户一个负载ip，根本查不出来是谁执行的

感觉应该不是这个sql打满的tikv，可能是别的sql，这个sql慢应该是果不是因，建议排查一下这期间的其他sql或资源情况。

非常特别极其认同

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。

一般经验：grafana+dashboard+数据库日志+系统日志 实际经验：凭感觉

【你最想实现的 TiDB 功能需求】 自定义函数 【你最喜欢的 TiDB 新特性 + 理由】 资源管控，对预算紧张极其友好 【你最想要周边心愿池里的哪个周边】 行李箱 【你考过哪些 TiDB 证书？】 PCTA\PCTP\PCSD 【你身边有多少位朋友在用 TiDB？】 10+

那估计就是GC的问题，逻辑删了，但是数据还在，要等数据GC了，才会显示region为空，进而合并region。 参考楼上大佬操作一下吧。

1、20w个region是包含了副本的，如果是3副本，实际就只有7w个region。 2、虽然只有6个表，但是第二个表有1.4亿条数据，360亿字节的数据和91亿字节的索引(不一定准确，因为按这个数据和索引长度换算下来只有45G大小，2.5T相差比较大)。 结合数据量，感觉7w多region也是可以接受的。毕竟除了数据还有索引。

region合并调优可以看看这里 https://docs.pingcap.com/zh/tidb/stable/massive-regions-best-practices#方法五开启-region-merge

leader是80，三副本，region就是80x3=240，从这方面看有20多万region是正常的。

就是你查的这个图，看这个图应该是没有空region啊

看看Grafana里的Region health

那可能是当时网络不好吧。如果要深究，就得看集群的各个日志，扒拉扒拉看看是什么问题

数据库对么？本地执行是正常的。

赞同楼上的说法，感觉TiFlash的加速效果比索引好太多了

建议通过扩缩容的办法，将故障节点逐个替换掉

这么一说我就明白了，因为haproxy就状态tidb节点上。根源还是没有配置透传。