自增ID比UUID更适合作InnoDB主键，因其插入时顺序追加、减少页分裂、降低索引碎片、提升范围查询性能；若必须用UUID，应转为BINARY(16)并避免作为主键，改用external_id冗余字段。
自增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。
- 先查依赖：
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去重，不影响主键连续性和查询路径。
- 避免冗余主键：绝不要同时建
PRIMARY KEY (id)和UNIQUE KEY (uuid)，写放大翻倍，维护成本陡增 - 迁移旧数据时，
external_id可批量用UUID_TO_BIN(UUID(), TRUE)填充，比字符串节省一半空间 - 如果必须用UUID主键，至少把
CHAR(36)换成BINARY(16)，这是MySQL 8.0里最容易被忽略的性能杠杆
实际改表或设计新表时，最容易被跳过的其实是索引依赖检查和应用层参数类型一致性——这两点不出问题则已，一出就是线上慢查询或数据查不到，但日志里连错误都不报。
