Kongdom
2020 年9 月 9 日 00:57
1
为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
【TiDB 版本】：TIDB v4.0
【问题描述】：
反模式 (最好别这么干！)
第一种，过度依赖单调递增的主键，AUTO INCREMENT ID 在传统的关系型数据库中，开发者经常会依赖自增 ID 来作为 PRIMARY KEY，但是其实大多数场景大家想要的只是一个不重复的 ID 而已，至于是不是自增其实无所谓，但是这个对于分布式数据库来说是不推荐的，随着插入的压力增大，会在这张表的尾部 Region 形成热点，而且这个热点并没有办法分散到多台机器。TiDB 在 GA 的版本中会对非自增 ID 主键进行优化，让 insert workload 尽可能分散。
第二种，单调递增的索引 (比如时间戳) 很多日志类型的业务，因为经常需要按照时间的维度查询，所以很自然需要对 timestamp 创建索引，但是这类索引的问题本质上和单调递增主键是一样的，因为在 TiDB 的内部实现里，索引也是一堆连续的 KV Pairs，不断的插入单调递增的时间戳会造成索引尾部的 Region 形成热点，导致写入的吞吐受到影响。
在官网看到这么篇文章，实际使用时，发现TIDB的自增ID在集群环境下不是单调递增的。那时间戳在集群环境下是单调递增的么？
1 个赞
QBin
2020 年9 月 9 日 03:18
2
目前 TIDB 的自增 ID 只保证唯一性。具体可以参考下：
https://docs.pingcap.com/zh/tidb/stable/mysql-compatibility#自增-id
文章主要指出的是单调递增的主键和单调递增的索引会引起的一些问题。特别是热点问题。如果只是有时间戳的列，但是该列上面没有索引。是不会引起索引热点问题的。具体热点问题可以参考下 asktug 和 官网上面的文章。
Kongdom
2020 年9 月 9 日 03:37
3
是的，这个我已经在实际应用中发现了。现在想找一个集群下保证自增的列，时间戳支持集群下自增么？
QBin
2020 年9 月 9 日 03:43
4
Kongdom
2020 年9 月 9 日 03:50
5
关键是在集群环境下是递增的么？
我在单例环境下单线程插入是递增的，但多线程批量插入就不是递增的了。
Kongdom
2020 年9 月 9 日 07:16
7
我看文档，
在 TiDB 集群中，[PD] 承担时间戳分配器的角色。
目前每个实例的tidb和pd是在一起的，这个时间应该是一致的
Kongdom
2020 年9 月 9 日 07:17
8
已经确定用时间戳作为解决方案了，后续在多实例集群中正式使用再看效果吧
Kongdom
2022 年10 月 31 日 19:11
10
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。
