insert 慢，有瓶颈，之前用一个 MYSQL8 就可以抗下5倍的量，请帮忙定位问题，谢谢！

tkaven · 2020 年8 月 27 日 13:50

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

【TiDB 版本】：
【问题描述】：

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

请问当前的瓶颈是在哪儿呢，目前只有 insert 还没有读，但是就是很慢：

tkaven · 2020 年8 月 27 日 16:27

其他指标：

不懂就问 · 2020 年8 月 28 日 02:07

部署的是什么版本？另外写入慢是压测的结果还是业务直接写入观察到的慢？可以根据这里的性能地图先排查下对应写入流程涉及到的指标是否有异常：https://github.com/pingcap/tidb-map/blob/master/maps/performance-map.png

tkaven · 2020 年8 月 28 日 02:16

你好 zhouyueyue，这里用的是 4.0.4 版本，然后是线上业务使用，
主要的语句是 insert on duplicate key update 用于更新统计分析的多行数据
也就两个库，每个库的表结构都是一样的，每个库也就8张表

麻烦看下监控给下相关提示哈，谢谢

还有就是监控里碎裂的红心和闪红具体是代表什么，怎么样才能恢复正常呢，非常感谢

不懂就问 · 2020 年8 月 28 日 02:45

初步判断很可能是写入热点问题：raftstore CPU 部分可以看到 store 1 的 CPU 使用率是其他两个节点的 2 倍，出现写入热点问题，影响写入的效率，见图：

特别是在数据量比较小的时候影响对写入的影响可能更明显（13 G 左右数据，142 个 region）可以先从解决写入热点部分进行优化，主要是两个思路：业务侧观察下是否有可能造成热点的写入，比如短时间内的密集顺序写入带主键的表；DB 侧可以对已有热点 region 进行 split 和 transfer 或者对新建表进行改造，参考文档

https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices

另外看截图二里面有部分空 region（小于 1M），是否有进行过 drop、truncate 或者完全删除表数据操作，可以使用 table 的 merge 功能合并空 region（空 region 占比将近 1/4），参考文档 region merge 慢部分

https://docs.pingcap.com/zh/tidb/dev/pd-scheduling-best-practices#region-merge-速度慢

红心标注的是一些重要的监控指标，异常的话对服务影响很大，需重点关注。先按照上面的分析处理下 region 的热点和空 region 问题，调整完之后观察下，看下写入效率是否有提升。