TiDB 中的自增主键有哪些使用限制，应该如何避免？
全文目录：
前言
今天我要给大家分享一些自己日常学习到的一些知识点，并以文字的形式跟大家一起交流，互相学习，一个人虽可以走的更快，但一群人可以走的更远。
我是一名后端开发爱好者，工作日常接触到最多的就是Java语言啦，所以我都尽量抽业余时间把自己所学到所会的，通过文章的形式进行输出，希望以这种方式帮助到更多的初学者或者想入门的小伙伴们，同时也能对自己的技术进行沉淀，加以复盘，查缺补漏。
小伙伴们在批阅的过程中，如果觉得文章不错，欢迎点赞、收藏、关注哦。三连即是对作者我写作道路上最好的鼓励与支持！
前言
在关系型数据库设计中，自增主键（Auto-Increment Primary Key）是一种非常常见的实现方式。自增主键的优点在于其简单、直观，能够为每一条记录生成唯一的标识符。然而，TiDB 作为一款分布式数据库，其架构与传统单机数据库不同，因此在使用自增主键时需要特别注意。
本文将详细解析 TiDB 中自增主键的使用限制，解释这些限制产生的原因，并提供避免问题的建议和最佳实践。通过深入理解 TiDB 对自增主键的支持方式，开发者可以更好地设计数据库表结构，避免潜在的问题。
TiDB 中自增主键的使用限制
TiDB 的设计理念是兼容 MySQL，因此大多数情况下，TiDB 支持与 MySQL 类似的自增主键机制。然而，由于 TiDB 是分布式架构，在自增主键的实现上与单机数据库有显著差异。因此，使用自增主键时需要特别注意以下限制：
1. 自增主键的分布式特性
在单机数据库中，自增主键通常是单调递增的，每次插入一条新记录时，主键值都会增加 1。然而，TiDB 是分布式数据库，多个节点同时进行数据写入时，无法保证自增主键的单调性。具体表现为，TiDB 的自增主键可能会存在跳跃、不连续的现象。
例子：
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(50)
);
在单机数据库中，插入多条记录时，id 字段的值可能是 1, 2, 3, 4。然而在 TiDB 中，多个节点并发写入时，主键值可能是 1, 4, 7, 10，这种不连续性对某些业务场景（如主键顺序性依赖）可能带来影响。
2. 批量分配导致的主键不连续
TiDB 为了提高并发性能，会批量分配自增主键值给不同的节点，这也是导致主键不连续的原因之一。每个节点分配到一段连续的主键值，但在多节点同时写入的情况下，最终的数据主键值看起来是不连续的。
例子：
假设 TiDB 中有三个节点，每个节点分配 100 个主键值范围：
- 节点 A 分配到主键值 1-100；
- 节点 B 分配到主键值 101-200；
- 节点 C 分配到主键值 201-300。
如果在节点 A 和节点 B 同时插入数据，可能会出现如下的主键序列：1, 2, 101, 102, 3, 103，这对需要主键顺序递增的应用程序来说，可能会带来不必要的复杂性。
3. 自增主键不保证顺序性
自增主键的另一个限制是：在 TiDB 中，即使没有并发写入，自增主键也不一定保证顺序性。TiDB 的底层存储使用 Raft 协议进行数据分片和复制，主键的生成是全局分配的，因此不会严格按照插入顺序进行递增。
在分布式系统中，不同节点的写入顺序不一定一致，最终会导致自增主键的顺序与写入时间无关，这可能影响某些需要按主键顺序进行查询的业务逻辑。
4. 自增主键可能导致热点问题
在 TiDB 中，如果使用自增主键作为索引，可能导致 写入热点问题。这是因为自增主键总是插入在索引的尾部，而 TiDB 的分片机制可能无法将所有的写入均匀分布到不同的分片上，从而导致某个分片承载了大部分的写入请求，形成性能瓶颈。
写入热点的影响：
- 某个分片（region）可能会成为写入的瓶颈，导致整体性能下降。
- 高并发下，该分片的负载过高，可能导致延迟增加或超时。
如何避免自增主键的使用问题
为了避免上述问题，在 TiDB 中使用自增主键时，需要采取一些优化策略和设计模式。
1. 使用 UUID 或自定义唯一标识符
为了避免自增主键的不连续性和顺序性问题，开发者可以选择使用 UUID 或其他自定义的唯一标识符。UUID 生成算法可以在分布式系统中确保唯一性，并且不依赖于全局锁定或协调。
CREATE TABLE users (
id CHAR(36) PRIMARY KEY,
name VARCHAR(50)
);
使用 UUID 作为主键可以避免自增主键带来的热点问题，同时提高插入并发性。不过，UUID 相比于整数主键，会占用更多的存储空间，并且在查询时性能可能略有下降。
2. 使用 AUTO_RANDOM 代替 AUTO_INCREMENT
TiDB 提供了 AUTO_RANDOM 特性，用来解决自增主键带来的热点问题。AUTO_RANDOM 会为主键随机分配一个值，从而将写入均匀分布到不同的分片，避免热点问题。
CREATE TABLE users (
id BIGINT PRIMARY KEY AUTO_RANDOM,
name VARCHAR(50)
);
AUTO_RANDOM 确保了主键的唯一性，同时不会像 AUTO_INCREMENT 那样总是递增，从而有效避免了热点问题。
3. 合理分配自增主键范围
如果必须使用自增主键，可以通过在应用层对自增主键进行范围分配，以减少分布式环境中不连续的问题。例如，将主键按照不同的节点预先分配不同的范围，节点 A 使用 1-1000，节点 B 使用 1001-2000 等，这样可以减少并发写入时主键的不连续性。
ALTER TABLE users AUTO_INCREMENT = 1001;
通过这种方式，尽管不同节点之间的主键值不连续，但同一个节点的自增主键是连续的，可以一定程度上减少不连续性对应用的影响。
4. 调整表设计，避免顺序依赖
如果应用对数据的插入顺序有较高要求，可以考虑调整表设计，避免依赖自增主键的顺序性。例如，可以引入其他标识字段（如时间戳或业务 ID）来记录数据的插入顺序，而非依赖主键的顺序性。
CREATE TABLE orders (
order_id BIGINT PRIMARY KEY AUTO_RANDOM,
user_id INT,
order_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
在这个例子中，order_time 记录了订单的创建时间，应用程序可以基于 order_time 进行排序，而不依赖 order_id 的顺序性。
实战案例：优化自增主键的设计
假设我们有一个电商系统，需要为每个用户生成唯一的订单编号。初始设计使用了自增主键：
CREATE TABLE orders (
order_id INT AUTO_INCREMENT PRIMARY KEY,
user_id INT NOT NULL,
product_id INT NOT NULL,
order_date DATETIME DEFAULT CURRENT_TIMESTAMP
);
在高并发环境下，我们发现自增主键导致了写入热点，某些节点出现了性能瓶颈。为了优化这个设计，我们可以改用 AUTO_RANDOM 或 UUID 作为主键：
使用 AUTO_RANDOM：
CREATE TABLE orders (
order_id BIGINT PRIMARY KEY AUTO_RANDOM,
user_id INT NOT NULL,
product_id INT NOT NULL,
order_date DATETIME DEFAULT CURRENT_TIMESTAMP
);
通过 AUTO_RANDOM，我们避免了写入热点问题，分布式环境下每个节点的写入负载更加均匀。
使用 UUID：
CREATE TABLE orders (
order_id CHAR(36) PRIMARY KEY,
user_id INT NOT NULL,
product_id INT NOT NULL,
order_date DATETIME DEFAULT CURRENT_TIMESTAMP
);
UUID 保证了主键的唯一性，适合需要跨多个系统同步数据的场景，尽管它会占用更多的存储空间，但能确保数据的唯一性和灵活性。
总结
在 TiDB 中，自增主键虽然简洁直观，但在分布式环境下存在一些使用限制，如主键不连续、无法保证顺序性以及写入热点问题。通过采用合理的优化策略，如使用 AUTO_RANDOM、UUID 或自定义唯一标识符，开发者可以有效避免这些问题，提升系统的性能和稳定性。
合理规划数据库表的设计，并结合业务需求选择适当的主键策略，是确保 TiDB 在大规模、高并发环境下平稳运行的关键。希望通过本文
的讲解，大家能够在实际项目中更好地运用这些技巧，避免常见的自增主键使用问题。
… …
文末
好啦，以上就是我这期的全部内容，如果有任何疑问，欢迎下方留言哦，咱们下期见。
… …
学习不分先后，知识不分多少；事无巨细，当以虚心求教；三人行，必有我师焉！！！
wished for you successed ！！！
⭐️若喜欢我，就请关注我叭。
⭐️若对您有用，就请点赞叭。
⭐️若有疑问，就请评论留言告诉我叭。
原文地址：https://blog.csdn.net/weixin_66592566/article/details/142675668
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！