【 TiDB 使用环境】生产环境
【 TiDB 版本】 6.1.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】 TiKV资源使用不均，sql执行慢
【资源配置】
【附件：截图/日志/监控】
看下region是否出现热点问题
1、 用 pd-ctl 手动转移hot region到负载低的节点；
2、针对于热点key导致的hot region需要手动split hot region；
3、以上操作可能需要等待调度，调度参数可以视情况修改
官网文档：https://docs.pingcap.com/zh/tidb/stable/pd-control#operator-check--show--add--remove
检查下存储使用率，没有达到60% 的阈值吧
没有的。
根据这个图判断，这个是明显的热点问题，如果是读热点，可以处理的办法还是挺多的吧。
-
尝试split它，拆分1000不够的话，可以再试试再得再细一些
-
读热点，如果是小表频繁访问引起的热点，如果小于64MB且更新不频繁，则设置为缓存表，直接缓存到tidb-server的内存
-
或者通过set config tikv split.qps-threadshold=3000超过3k的QPS，或set config tikv split.byte-threshold=30超过30MB的访问流量，触发系统的自动打散功能，使之均衡
-
或者，如果是读热点，也不是小表，则可能是执行计划问题，确认是否优化器选择索引错误
2 个赞
索引热点，表很大，就是很多的sql用的一个索引
ERROR 1105 (HY000): Split index region num exceeded the limit 1000。。。无法拆分大于1000，是有什么参数设置嘛？
它们使用的这个时间索引是合理的吗？
如果是不合理的，可以指定使用其他索引，可以根据执行计划不准的操作来处理
如果是合理的，
- 说明就是这么热，可以不断通过拆分、迁移热点region的手段操作，拆得尽可能细一些；
- 或者结合业务的情况，看某些业务能否用上别的索引，以减轻热点问题
- 再有的操作，就是扩容tikv实例，
- 使用 NVME 性能更好的SSD磁盘
1 个赞
印象中应该是有个 split-region-max-num 参数，可以调整 SPLIT TABLE 语法允许的最大 Region 数量
具体可以查一查官网
我晓得为什么拆分没效果了。拆分完毕后又合并了。
大兄弟，你们这边后面是怎么处理的？分享下处理经验