生产环境 TiDB v6.5，三台 TiKV，每天批量导入日志数据，表用自增 bigint 主键。Grafana 里看写入几乎全压在一个 region 上，单台 TiKV 的 CPU 持续 90% 以上，另外两台很闲。试过重建表加 SHARD_ROW_ID_BITS=4 预打散，热点图上有缓解，但整体导入吞吐没明显提升。AUTO_RANDOM 又要改主键生成方式，业务侧改动不小。想请教下大家这类顺序写入热点一般怎么处理？两种方案怎么选？打散后对点查性能影响大吗？
这个场景建议优先考虑 AUTO_RANDOM。SHARD_ROW_ID_BITS 只对隐藏 rowid 生效，你用自增主键的话它其实没真正打散主键索引，热点缓解有限是正常的，吞吐上不去也说明瓶颈还在索引写入。
AUTO_RANDOM 是直接作用在主键上的，把主键高位随机化，写入能真正分散到多个 region。业务侧改动其实不大，插入时不用指定主键值，让 TiDB 自动生成即可，读取时主键照常当字符串/整数用。
1 个赞
能从热点图定位到单 region，排查思路没问题。但有个坑要提醒：bigint 自增主键默认是聚簇索引，行 ID 就是主键值本身，SHARD_ROW_ID_BITS 其实不生效，除非建表时显式 NONCLUSTERED，你们看到的缓解可能只是重建表带来的。日志场景我更推 AUTO_RANDOM：只要业务不依赖 ID 单调性，插入后拿 LAST_INSERT_ID() 的返回值做点查，性能和原来没差别，代价只是按 ID 的范围查询失效。至于吞吐没涨，可以再确认下 16 个 region 够不够，瓶颈也可能其实在导入端并发上。