MySQL 主键不推荐使用 UUID 的深层原因

1. 存储空间问题

存储大小对比

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

sql 复制代码

-- 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 聚簇索引特性

sql 复制代码

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

性能影响对比

sql 复制代码

-- 场景：插入100万条数据
-- 使用自增ID
INSERT INTO table (name) VALUES ('name');  -- 直接追加到B+树末尾

-- 使用UUID
INSERT INTO table (id, name) VALUES (UUID(), 'name');  
-- 需要：1. 在B+树中寻找插入位置 2. 可能导致页分裂 3. 碎片化

3. 页分裂与碎片化

页分裂过程

sql 复制代码

原始页（已满）：[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 工作原理

sql 复制代码

-- 自增ID：连续的数据更容易一起被缓存
-- 读取用户1-100的数据可能只需要1-2次磁盘I/O

-- UUID：数据分散在不同页中
-- 读取100个用户数据可能需要100次磁盘I/O

5. 具体性能测试对比

测试数据

sql 复制代码

-- 创建测试表
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的场景

sql 复制代码

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

不适合使用UUID的场景

sql 复制代码

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

7. 优化方案

方案1：组合使用

sql 复制代码

-- 使用自增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

sql 复制代码

-- 使用时间有序的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）

sql 复制代码

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

8. MySQL 8.0 的改进

sql 复制代码

-- 生成有序UUID
SELECT UUID_TO_BIN(UUID(), 1);  -- 有序
SELECT UUID_TO_BIN(UUID(), 0);  -- 无序

-- 反向转换
SELECT BIN_TO_UUID(binary_uuid, 1);

9. 监控指标

sql 复制代码

-- 查看碎片化程度
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或组合方案，并监控性能影响。