为什么MySQL推荐使用自增主键?

文章探讨了MySQL推荐使用自增主键的原因,自增主键在插入新记录时能保持顺序,避免频繁移动和碎片,提高索引结构紧凑性。相比之下,非自增主键可能导致更多磁盘I/O和索引重构。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

为什么MySQL推荐使用自增主键?

主键数据记录本身被存于主索引(一棵B+Tree)的叶子节点上,这就要求同一个叶子节点内(大小为一个内存页或磁盘页)的各条数据记录按主键顺序存放,因此每当有一条新的记录插入时,MySQL会根据其主键将其插入适当的节点和位置,如果页面达到装载因子(InnoDB默认为15/16),则开辟一个新的页(节点),如果表使用自增主键,那么每次插入新的记录,记录就会顺序添加到当前索引节点的后续位置,当一页写满,就会自动开辟一个新的页;

而如果使用非自增主键,由于每次插入主键的值近似于随机,因此每次新记录都要被插到现有索引页的中间某个位置,此时MySQL不得不为了将新记录插到合适位置而移动数据,甚至目标页面可能已经被回写到磁盘上而从缓存中清掉,此时又要从磁盘上读回来,这增加了很多开销,同时频繁的移动、分页操作造成了大量的碎片,得到了不够紧凑的索引结构,后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面

参考文献

### 在 MySQL 中同时使用 UUID 和 自主键的方法 #### 方法概述 为了充分利用两种主键的优势,在实际应用中可以选择创建两个字段分别用于存储自 ID 和 UUID。通常情况下,自 ID 被设为主键并负责唯一标识记录;而 UUID 则作为一个辅助列存在,主要用于跨系统识别或分布式环境下的数据同步。 #### 实现方式 可以通过定义复合主键的方式来实现这一目标: ```sql CREATE TABLE example_table ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, uuid CHAR(36) NOT NULL DEFAULT (UUID()), name VARCHAR(255), PRIMARY KEY (id), -- 设置自ID为主键 UNIQUE INDEX idx_uuid(uuid)-- 添加唯一索引到UUID上以确保其唯一性 ); ``` 上述 SQL 语句展示了如何在一个表内同时维护 `id`(自整数型)和 `uuid` 字段,并通过设置合适的约束条件来保障两者的特性和功能[^1]。 #### 注意事项 当采用这种方式时需要注意以下几点: - **性能影响**:虽然引入了额外的 UUID 字段,但由于查询操作主要依赖于效率更高的自主键,因此整体性能不会受到太大负面影响。 - **空间占用**:相比单纯的自主键方案,此方法确实加了每条记录所需存储的空间量,因为需要保存较长字符串形式的 UUID 值。 - **插入顺序问题**:由于自主键能够保证新纪录总是追加到最后位置,这有助于提高写入速度;而对于随机生成的 UUID,则可能引起页分裂等问题从而降低性能[^2]. #### 优点对比 | 特征 | 自主键 | UUID | | --- | --- | --- | | 数据长度 | 较短 | 较长 | | 插入性能 | 更高 | 可能较低 | | 分布式支持 | 不友好 | 支持 | 综上所述,在某些特定场景下,比如涉及到多数据库实例间的数据交换或是希望获得全局唯一的实体标识符的情况下,可以考虑这种混合模式的设计思路[^3]。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

拾光师

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值