MySQL 主键不推荐使用 UUID 的深层原因及解决方案_Mysql

1.存储空间问题

存储大小对比

主键类型	存储大小	示例值
bigint（自增）	8字节	1, 2, 3...
int（自增）	4字节	1, 2, 3...
uuid（字符串）	36字符（288位）	`uuid-xxxx-xxxx-xxxx`
uuid（二进制）	16字节	二进制格式

-- uuid 的两种存储方式
create table users_uuid_str (
    id char(36) primary key default uuid(),  -- 36字节
    name varchar(50)
);
create table users_uuid_bin (
    id binary(16) primary key,  -- 16字节，但仍然有其他问题
    name varchar(50)
);

2.索引性能问题（最核心问题）

innodb 聚簇索引特性

-- innodb 表结构示例
-- 数据实际按主键顺序存储在磁盘上
-- 自增id：数据物理存储是连续的
-- uuid：数据物理存储是随机的

性能影响对比

-- 场景：插入100万条数据
-- 使用自增id
insert into table (name) values ('name');  -- 直接追加到b+树末尾
-- 使用uuid
insert into table (id, name) values (uuid(), 'name');  
-- 需要：1. 在b+树中寻找插入位置 2. 可能导致页分裂 3. 碎片化

3.页分裂与碎片化

页分裂过程

原始页（已满）：[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
新插入uuid：需要插入到 5 和 6 之间
结果：
页1：[1, 2, 3, 4, 5]
页2：[uuid_value, 6, 7, 8, 9, 10]
问题：
1. 数据不再连续
2. 磁盘空间利用率下降
3. 查询需要更多磁盘i/o

4.缓存效率问题

innodb buffer pool 工作原理

-- 自增id：连续的数据更容易一起被缓存
-- 读取用户1-100的数据可能只需要1-2次磁盘i/o
-- uuid：数据分散在不同页中
-- 读取100个用户数据可能需要100次磁盘i/o

5.具体性能测试对比

测试数据

-- 创建测试表
create table test_autoinc (
    id bigint unsigned auto_increment primary key,
    data varchar(100)
) engine=innodb;
create table test_uuid (
    id char(36) primary key default uuid(),
    data varchar(100)
) engine=innodb;
-- 插入性能对比（100万行）
-- 自增id：约 30-40秒
-- uuid：约 90-120秒（慢2-3倍）
-- 查询性能对比（范围查询）
select * from test_autoinc where id between 100000 and 200000;
-- 使用聚簇索引，高效
select * from test_uuid where id > 'xxxx';
-- 索引效率低，需要更多随机i/o

6.实际场景分析

适合使用uuid的场景

-- 分布式系统，需要离线生成id
-- 数据需要合并的场景
-- 安全要求高，不希望暴露数据规模
-- 示例：移动设备离线数据同步

不适合使用uuid的场景

-- 高并发写入的oltp系统
-- 需要频繁范围查询的业务
-- 数据量大的表（>1000万行）
-- 示例：电商订单、用户表、日志表

7.优化方案

方案1：组合使用

-- 使用自增id作为主键，uuid作为业务id
create table users (
    id bigint unsigned auto_increment primary key,  -- 用于索引和关联
    uuid char(36) unique not null default uuid(),   -- 对外暴露
    name varchar(50),
    index idx_uuid(uuid)
);

方案2：有序uuid

-- 使用时间有序的uuid变体
-- mysql 8.0+ 的 uuid_to_bin 函数
create table users (
    id binary(16) primary key default (uuid_to_bin(uuid(), 1)),  -- 有序
    name varchar(50)
);
-- 参数1：将时间部分移到前面，提高顺序性

方案3：雪花算法（snowflake）

# 分布式id生成算法（64位）
# 结构：时间戳(41位) + 机器id(10位) + 序列号(12位)
# 优点：有序、分布式、高性能

8.mysql 8.0 的改进

-- 生成有序uuid
select uuid_to_bin(uuid(), 1);  -- 有序
select uuid_to_bin(uuid(), 0);  -- 无序
-- 反向转换
select bin_to_uuid(binary_uuid, 1);

9.监控指标

-- 查看碎片化程度
select 
    table_name,
    data_length,
    index_length,
    data_free,
    round(data_free/(data_length+index_length)*100, 2) as frag_percent
from information_schema.tables
where table_schema = database();
-- 监控插入性能
show engine innodb status;

10.决策指南

何时可以使用uuid？

✅ 数据量小（<100万行）
✅ 插入频率低
✅ 分布式系统必须使用
✅ 数据合并需求
✅ 安全要求高

应该避免使用uuid？

❌ 高并发写入系统
❌ 大数据量表
❌ 频繁范围查询
❌ 性能敏感系统
❌ 磁盘空间有限

总结

在大多数oltp场景中，自增整数主键是最优选择。uuid主要问题是破坏innodb聚簇索引的顺序性，导致页分裂、碎片化、缓存效率低下等问题。如果必须使用uuid，应优先考虑有序uuid或组合方案，并监控性能影响。

到此这篇关于mysql 主键不推荐使用 uuid 的深层原因的文章就介绍到这了,更多相关mysql主键不推荐使用uuid内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！

MySQL 主键不推荐使用 UUID 的深层原因及解决方案

2026年01月08日 • Mysql •我要评论