MySQL不建议用UUID等过长字段作主键，因其导致二级索引膨胀、页分裂频发、缓冲池命中率下降、B+树层级升高、磁盘I/O激增及网络内存开销加大。
MySQL 不建议用过长字段（比如身份证号、UUID、长字符串）当主键，核心原因在 InnoDB 存储引擎的聚簇索引机制——主键不只是标识记录，它直接决定了数据物理存储结构和所有二级索引的组织方式。
主键过长会放大索引空间与内存开销
InnoDB 的每个二级索引（非主键索引）叶子节点不存行指针，而是存对应的主键值。如果主键是 32 位 UUID 或 18 位雪花 ID，或更长的身份证号字符串，那每个二级索引项都要完整复制这个长值。数据量一大，索引体积剧增：
- 缓冲池（buffer pool）能缓存的索引页数量下降，磁盘 I/O 频率升高
- 单个索引页能容纳的键值数量减少，B+ 树层级变高，查询需更多层遍历
- 相同数据量下，磁盘占用翻倍甚至数倍，备份、复制、迁移成本同步上升
导致严重的页分裂与写入性能衰减
InnoDB 的聚簇索引按主键顺序物理存放数据。若主键完全随机（如 UUID），新记录无法追加到末尾，只能插入到中间某页——这极易触发页分裂（page split）：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 一页满时要拆成两页，产生大量碎片
- 频繁分裂带来额外的锁竞争、日志写入和磁盘随机写
- 插入吞吐量可能比自增主键低 3–5 倍，尤其在高并发写场景下
限制索引定义与扩展能力
主键本身也是索引，其长度受 InnoDB 索引键最大长度限制约束：
- 默认 ROW_FORMAT=COMPACT 下，单索引键上限为 767 字节
- 即使启用了
innodb_large_prefix并设为 DYNAMIC，上限也仅 3072 字节 - utf8mb4 字符集下，一个中文字符占 4 字节，255 字符就达 1020 字节——已逼近旧限制
- 主键过长，后续再想对其他字段建联合索引，很容易因总字节数超限而报错
Specified key was too long
增加网络与内存传输负担
主键参与几乎所有数据库交互环节：
- JOIN 操作中，主键值要在内存中多次比对和传递
- 外键约束检查、唯一性校验都依赖主键字段的完整比较
- 应用层序列化/反序列化、日志打印、监控埋点等都会携带该长字段，徒增带宽和 GC 压力
