tidb 查询产生慢SQL，怀疑是replace into性能问题

[zhengshibing]

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

• 【TiDB 版本】：3.0.8
• 【问题描述】：系统突然反应迟钝，从grafna监控上看有一台tikv的IO几乎100%
  
  

异常时间段的慢SQL信息
0709_2.rar (9.5 KB)

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出打印结果，请务必全选并复制粘贴上传。

[zhengshibing]

这个是问题时间段grafna监控数据
disk_tikv
tikv.rar (741.1 KB)

over_view
over_view.rar (1.2 MB)

tikv_detail(这两个要一起解压，是一个图片压成了两个包)
tikv_detail.part1.rar (4 MB) tikv_detail.part2.rar (2.0 MB)

[yilong (yi888long)]

1. 请在 tidb 慢日志中找一下，这个时间段是否存在消耗 IO 多的 sql。
2. 可以按照扫描的 key 多少先查找一下。

[zhengshibing]

1. 请问一下tidb的慢日志中，有命令找到按IO消耗排序的慢SQL吗，我使用的pt-degist-query无法按照IO消耗排序
2. replace into有主键，只有一条数据的

[yilong (yi888long)]

1. 可以看到 214 的时间很久

2. 可以看到 214 的盘 latency 很高

3. 请检查盘是否性能一致
4. 另外看下是否开启了 region merge
   
   
5. 每个 tikv 都有 9万多的region，可以考虑扩容节点，分散region数量。

[zhengshibing]

3. 三台TIKV磁盘性能是相同的，之前一直没有问题，就问题时间点突然214反应很慢了
4. 这个功能如何查看
5. 请问一台tikv的容量大小和region数量的建议合理范围是多少呢

[yilong (yi888long)]

3. 但是从latency来看，确实是，可以多观察一下，出问题时，是否都是这个盘慢
4. [FAQ] 解决已经开启 region merge， empty-region-count 仍然很多问题 可以搜一下region merge
5. 一个实例，不超过 2T ， region 一般是 96 M 切分，所以建议是在 2 万多的 region 数量就可以了。

[zhengshibing]

4. 我的集群中，没有开启region merge

   
   
   系统中有4W的空region，是正常现象吗，我们系统中，应该是很少有删除或者更新操作的，都是直接插入和查询

5. 一个实例，是指一个TIKV节点吗？还是说整个TIDB集群呢

[yilong (yi888long)]

4. 可以考虑开启
5. 一个 store，就是一个 tikv