mysql数据库主键类型对性能的影响_使用自增整数优于UUID

自增INT主键比VARCHAR(36)UUID快得多，因自增ID顺序插入减少页分裂、提升缓存命中率，而UUID随机插入导致频繁页分裂、随机I/O和索引碎片；INSERT延迟从0.2--0.5ms升至1.5--4ms，ORDER BY id退化为全表扫描，单页存储量下降约60%。为什么自增 INT 主键比 VARCHAR(36) UUID 快得多因为 B+ 树索引的页分裂和插入局部性完全不同。自增整数按顺序写入，新记录总在索引末尾追加，页分裂少、缓存友好；UUID 是随机字符串，插入位置完全不可预测，导致频繁页分裂、大量随机 I/O 和索引碎片。INSERT 性能差距在真实业务中有多明显在每秒写入 500+ 行的订单表中，用 BIGINT 自增主键时 INSERT 延迟稳定在 0.2--0.5ms；换成 VARCHAR(36) UUID 后，延迟跳到 1.5--4ms，高峰期甚至触发 InnoDB 行锁等待。这不是理论值，是慢日志里能直接捞出来的 Query_time。UUID 每次插入都要搜索整个 B+ 树定位插入点，而自增 ID 只需定位到最后一页InnoDB 的聚簇索引直接按主键排序存储数据行，UUID 导致物理存储乱序，SELECT ... ORDER BY id 变成全表扫描级开销innodb_page_size=16K 下，一个页存约 100 条自增记录，但可能只存 30--40 条 UUID 记录（因字符串长度和填充碎片）想用 UUID 真就完全不行？这几个折中方案得知道如果业务强依赖分布式生成 ID（比如分库分表前就定死了 UUID），至少别用原生 UUID() 函数------它返回的是标准格式带横杠的字符串，多占 4 字节且无法走索引优化。 arXiv Xplorer ArXiv 语义搜索引擎，帮您快速轻松的查找，保存和下载arXiv文章。