随机写入真的是最好的选择吗?

  • UUID 是 128 bit 字符串, 不适合作为主键: 不仅长度大, 字符串比较的性能也不好. 实际上, 如果主键不是整型字段, TiDB 会使用自增的 rowid 作为"隐式主键"——把数据存入 TiKV 时实际作为 key 的是 rowid. 也就是说, 如果使用字符串主键和组合主键(无论构成主键的各个字段是否都为整型), 实际效果等同于自增 ID 做主键. 我们的经验里, 即使用了 SHARD_ROW_ID_BITS, 也不能完全避免写入性能问题.
  • 如果数据并发写入量较大, 主键还是要使用唯一的 INT/BIGINT 值, 并将其随机打散. 有多种做法可以生成唯一 ID, 比如较为常用的 Twitter Snowflake 算法; 唯一 ID 往往是单调递增或者趋势递增的, 将其随机化打散的常用做法是 bit-reverse, 10100 --> 00101. 关于高并发唯一序列号生成方案, 这里有一些介绍.
  • TiDB 3.1 开始引入 AUTO_RANDOM ID. 非常期待这个功能进入实用阶段.相信它能降低生成随机唯一 ID 的门槛, 并将 “每一个 TiDB 表都要有一个随机分布的整型主键” 固化为和 “每一个 MySQL 表都要有一个单调递增的整型主键” 一样的日常开发规范.

关于热点和高并发写入, 不妨参考这两篇: 1 2

3 个赞