mysql为什么建议主键采用自增ID而非UUID_主键聚簇索引排序优化-mysql教程-PHP中文网

自增ID比UUID更适合作InnoDB主键，因其插入时顺序追加、减少页分裂、降低索引碎片、提升范围查询性能；若必须用UUID，应转为BINARY(16)并避免作为主键，改用external_id冗余字段。

mysql为什么建议主键采用自增id而非uuid_主键聚簇索引排序优化

自增ID让InnoDB聚簇索引物理存储更紧凑

InnoDB的主键就是聚簇索引，行数据直接按主键顺序存放在B+树叶子节点里。自增ID（如BIGINT AUTO_INCREMENT）插入时总是追加到索引末尾，新页只需顺序分配，几乎不触发页分裂。而UUID是随机字符串，每次插入位置不可预测，B+树必须频繁做节点拆分、合并和指针重连——实测百万级写入，UUID表的索引碎片率比自增ID高3倍以上。

观察索引碎片：用SHOW TABLE STATUS LIKE 'users'看Data_free值，持续偏高说明分裂严重
不要用UUID()原生函数：它返回'550e8400-e29b-41d4-a716-446655440000'这种带横杠的36字符格式，不仅多占4字节，还因字符排序规则（如utf8mb4_general_ci）导致比较慢
如果非用UUID，MySQL 8.0+务必用UUID_TO_BIN(UUID(), TRUE)转成BINARY(16)，并把时间戳高位前置，提升局部性

UUID做主键会导致范围查询变慢甚至失效

聚簇索引的物理顺序直接影响查询效率。WHERE id BETWEEN 1000 AND 2000这类范围扫描，在自增ID下只需读取连续几个数据页；但UUID主键下，这些“逻辑相邻”的ID在磁盘上可能散落在数百个不同页里，变成随机IO，缓存命中率暴跌。更隐蔽的问题是：很多ORM默认把数字ID参数当字符串传，比如WHERE id = '12345'查BIGINT主键，MySQL会隐式类型转换，但查CHAR(36)主键时若传错格式（漏横杠、大小写混用），就完全命中不了索引。

检查执行计划：对UUID主键表跑EXPLAIN SELECT * FROM users WHERE id = '9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d'，确认type是const而非ALL
应用层传参必须严格匹配字段定义：CHAR(36)字段不能接受REPLACE(uuid, '-', '')后的32位字符串，否则索引失效
联合索引里别把UUID放最左：比如(user_id, created_at)，若user_id是UUID，整个索引的范围扫描能力基本归零

ALTER TABLE改主键不是改个类型那么简单

线上表想从UUID主键切回自增ID，ALTER TABLE users MODIFY id BIGINT AUTO_INCREMENT会失败——因为主键变更要重建整个聚簇索引，千万级表锁表时间常超20分钟，且外键、二级索引、触发器全受影响。更麻烦的是，如果其他表有FOREIGN KEY (order_id) REFERENCES users(id)，而order_id字段还是VARCHAR(36)，直接改users.id会触发外键约束报错ERROR 1832 (HY000): Cannot change column 'id': used in a foreign key constraint。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

先查依赖：SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'users' AND REFERENCED_COLUMN_NAME = 'id'
逐个修改关联表字段类型，注意顺序：先改子表字段为BIGINT，再改父表主键，否则外键校验通不过
应用代码里所有WHERE id = ?都要同步改参数类型，Java里Long不能自动转成UUID字符串，否则查不到还静默失败

真正需要UUID时，别让它当主键

分布式场景下，UUID的价值在于全局唯一和去中心化生成，但这不等于它必须是主键。更合理的做法是保留id BIGINT AUTO_INCREMENT PRIMARY KEY，另加一个external_id CHAR(36) UNIQUE NOT NULL存UUID，业务对外暴露external_id，内部关联仍走id。这样既享受自增ID的索引性能，又保留UUID的集成便利性——跨库合并时只用处理external_id去重，不影响主键连续性和查询路径。