tidb数据表用你自增好，还是random好

🛰️ 应用开发者专区
1

tidb数据表用你自增好，还是random好，如果是自增会不会出现热点问题

2

random好，自增会出现热点问题

3

但业务中可能出现用id去深度翻页查询，不自增好像不好查

4

如果业务必须依赖id的连续递增性，那只能用AUTO_INCREMENT

5

热点 未必会有，看你们业务量，用了nvme ssd并且还有一秒写入10万条以上数据要求可以考虑下这个问题，如果io负载不高自增就行

6

建表的时候提前拆分region，避免热点问题就行了。只不过要注意建表以后马上要开始导入数据，不然region会合并的

7

嗯，根据业务情况去

8

这个针对历史数据迁移可能用得到

9

根据业务需求设计

10

tidb用自增和mysql不同，不同版本tidb自增也有不同

AUTO_INCREMENT 是用于自动填充缺省列值的列属性。当 INSERT 语句没有指定 AUTO_INCREMENT 列的具体值时，系统会自动地为该列分配一个值。

出于性能原因，自增编号是系统批量分配给每台 TiDB 服务器的值（默认 3 万个值），因此自增编号能保证唯一性，但分配给 INSERT 语句的值仅在单台 TiDB 服务器上具有单调性。

在 TiDB 各个版本中，AUTO_ID_CACHE 设置为 1 都表明 TiDB 不再缓存 ID，但是不同版本的实现方式不一样：

  • 对于 TiDB v6.4.0 之前的版本，由于每次分配 ID 都需要通过一个 TiKV 事务完成 AUTO_INCREMENT 值的持久化修改，因此设置 AUTO_ID_CACHE 为 1 会出现性能下降。
  • 对于 v6.4.0 及以上版本，由于引入了中心化的分配服务，AUTO_INCREMENT 值的修改只是在 TiDB 服务进程中的一个内存操作，相较于之前版本更快。
  • 将 AUTO_ID_CACHE 设置为 1 表示 TiDB 使用默认的缓存大小 30000。
11

random

12

并发不大用自增，并发大用random

14

不对写入性能有极致的要求，自增就行

15

主键一般不用于业务查询，不建议用深度分页，性能不好的
写入量大的话用random，反之用自增

16

自增就行

17

random好，自增会出现热点问题，即使自增也不是全局连续的

18

自增，除非业务有特别要求

19

若有深度分页，建议自增

20

看业务上是用于前端的还是后端的，前端的要分页，使用AUTO_INCREMENT，如果是纯后端业务使用，又怕热点，那就使用random

21

random好