当txnkv压测，写数据用了事务的两阶段提交时，写入key的字节数越大qps明显下降许多，但资源是并没有吃满的：
1 个赞
看起来是产生写入热点了，参考下这个处理方案：
https://docs.pingcap.com/zh/tidb/dev/high-concurrency-best-practices
1 个赞
没懂这个解决方式，是部署完之后需要通过sql来改变Region 切分嘛？
我是将数据写入至tikv，和tidb没啥联系呢
帖子内容我帮你编辑了一下，
当rawkv场景压测时
开头改成了这个。
我是txnkv压测，写数据用了事务的两阶段提交
1 个赞
加上了
蹲回复，这个解决了马上就需要在线上使用了，压测几天了qps上不去，大概率出现在这个问题，服务器硬件方便我已经升级了，16c128g 4tb，硬盘是本地nvme
二楼正解，重点看其中热点问题的规避方法
可我是tikv啊，不是tidb
没有人能够解释一下为什么会数据倾斜吗，该如何解决啊
几副本啊，一般3副本的情景下就算有热点，压力也不会偏太多的
三副本，但看grafana的情况，压力都集中再一台了
热点就是tikv节点，不是tidb节点。比如顺序写入1、2、3、4、5，虽然是三个节点，但数据一般都会写入一个节点。但如果是随机写入1、222、333333、4、555，这样一边写入不同的节点。
可我写入的key是uuid，并没有顺序的
看这里，貌似也会产生热点，设置显式的 CLUSTERED 试试
https://docs.pingcap.com/zh/tidb/stable/uuid#uuid-格式二进制顺序和聚簇主键
检查 Region 分布 ：通过 SHOW TABLE REGIONS 查看目标表的 Region 分布情况，确认是否存在 Region 集中在单个 TiKV 节点的现象
哪个库啊？
那是不是可以理解为，我压测数据生成的key不要使用uuid.NewString()而是直接用随机的int是吧，你这个是tidb的啊，我并没有用到tidb，我是三个tikv 上方的方式并不能解决我目前的问题
是的，这两种方法都可以。或者参考一下这里 https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices#热点问题的规避方法
