主键过大严重拖垮二级索引性能，因InnoDB二级索引叶子节点存储主键值，UUID等长主键导致索引体积激增、B+树变深、缓存效率下降；应改用BIGINT自增主键并重建索引释放空间。
主键太大直接拖垮所有二级索引
MySQL 的 InnoDB 引擎中，二级索引（非聚簇索引）的叶子节点不存行数据，而是存主键值。这意味着：主键越长，每个二级索引条目就越大，索引树层级越深、磁盘占用越多、缓存效率越低。一个 VARCHAR(255) 主键可能让 idx_status 和 idx_created_at 的体积翻 3–5 倍——这不是夸张，是 B+ 树结构决定的硬约束。
为什么 UUID 或长字符串主键特别危险
常见错误是直接用 UUID()、MD5() 或业务长码（如订单号 ORDER_20260508114522993847）当主键。它们的问题不是“不能用”，而是：
-
UUID是 128 位随机值，插入时几乎必然导致页分裂，B+ 树频繁重组织，INSERT性能断崖下跌 - 二级索引每条记录都得存完整 UUID 字符串（36 字节或更多），而
INT UNSIGNED只需 4 字节 —— 单条记录差 9 倍，百万级表就是 GB 级浪费 - InnoDB 缓冲池（
innodb_buffer_pool_size）本就有限，大量无效索引页挤占有效热数据空间
安全替换主键的实操步骤（不停服）
已有大主键表，又不能停机重建？走以下路径，风险可控：
- 新增自增列：
ALTER TABLE orders ADD COLUMN id_new BIGINT UNSIGNED AUTO_INCREMENT FIRST, ADD PRIMARY KEY (id_new);（注意：加FIRST避免锁表太久；InnoDB 允许在有主键时加新主键，但会隐式删旧主键） - 补全新主键值（若原主键无序，需按业务时间/ID 排序填充）：
UPDATE orders o JOIN (SELECT @row:=@row+1 AS rn, id_old FROM orders, (SELECT @row:=0) r ORDER BY created_at) t ON o.id_old = t.id_old SET o.id_new = t.rn; - 将原主键降为唯一索引（保留业务语义）：
ALTER TABLE orders DROP PRIMARY KEY, ADD UNIQUE INDEX uk_order_id_old (id_old); - 逐个重建二级索引，强制使用紧凑格式：
ALTER TABLE orders DROP INDEX idx_status, ADD INDEX idx_status (status) ALGORITHM=INPLACE, LOCK=NONE;
关键点：ALGORITHM=INPLACE 避免全表拷贝，LOCK=NONE 允许并发 DML（需 MySQL ≥5.6 + 行格式为 DYNAMIC）。
新建表必须遵守的主键铁律
从零建表时，别给自己挖坑：
- 除非强依赖分布式 ID 生成逻辑，否则一律用
BIGINT UNSIGNED AUTO_INCREMENT（INT在千万级后易溢出） - 绝对不要用
VARCHAR、TEXT、JSON或函数结果（如UUID()）作主键 - 如果业务必须暴露短链 ID（如
/u/abc123），用独立字段存储并加唯一索引，主键仍走自增整数 - 确认表行格式：
SHOW CREATE TABLE orders;中应含ROW_FORMAT=DYNAMIC（默认），避免COMPACT对长字段的额外开销
最常被忽略的一点：即使你把主键改小了，旧二级索引不会自动收缩——必须显式 DROP 并 ADD 才能释放空间。不重建，白优化。
