UUIDv7：128bit，时间有序 UUID，可应用端 / 数据库生成，MySQL 推荐存储为
BINARY(16)，不建议存 varchar (36) 字符串自增 ID：数据库 AUTO_INCREMENT，BIGINT，数据库端生成
基础特性
自增 ID 适用场景 ✅
单库单表，绝大多数普通业务表
如用户表、订单表、商品表，单实例 MySQL，追求数据库写入性能、索引效率。
不需要对外暴露 ID，仅内部主键
ID 只在程序内部关联，API 对外返回业务编码，不直接返回主键 ID。
追求小存储、高性能，表数据量大
bigint 占 8 字节，关联其他表作为外键时，索引体积小，join 更快。
不需要跨库、多实例数据合并
不做跨库迁移、多库数据合并。
需要简单人工排查、日志查看
日志、调试时数字 ID 直观。
⚠️缺点：
对外暴露容易被爬虫遍历（
/user/1001、/user/1002）；分库分表多实例直接用自增会 ID 冲突，必须搭配雪花算法、号段模式等 ID 生成器；
数据库故障恢复，自增序列会跳号。
自增 ID ❌不适合
多库独立写入，后续要合并数据；
主键直接对外 API 返回，不想被猜测业务规模；
应用离线先构造实体，还未插入数据库就要拿到主键 ID。
UUID 适用场景 ✅
注意：优先选择 UUID v7（时间有序 UUID），不要用 v4 完全随机 UUID，v4 插入 MySQL 会严重影响 InnoDB 性能。
应用层提前生成 ID
还没插入数据库，业务代码就需要拿到主键 ID；分布式服务，不需要访问 DB 就生成唯一键。
多库、多实例、分库分表、数据合并
多个独立数据库写入，后续需要合并数据，不会主键冲突。
主键直接对外暴露，防止遍历、猜业务量级
API 直接返回主键，不想对手通过 ID 猜出用户量、订单量。
离线数据导入、异构系统对接
外部系统导入数据，自带唯一标识。
没有中心化 ID 发号服务的分布式环境
⚠️缺点：
v4 完全随机：InnoDB 主键索引随机插入，大量页分裂，插入性能暴跌；
存储开销大，外键索引体积膨胀；
可读性差，日志排查不方便；
默认字符串形式占用更大，建议存二进制 (16 字节) 而不是 36 位字符串。
UUID ❌不适合
超高写入 QPS，且使用 UUID v4（无序）作为 InnoDB 主键；
表数量极大，大量外键关联，希望尽可能压缩存储；
数据库性能资源紧张，没有使用有序版本 UUID (v7)。
常见误区
❌ 分布式就必须用 UUID
分布式更多用雪花算法、号段 ID 生成器，64 位 long，兼顾有序、全局唯一，存储小，比 UUID 更适合 MySQL。UUID 只是其中一个选项，不是最优。
❌ UUID 全部性能很差
UUID v7 是时间有序 UUID，128bit，保留全局唯一，同时插入 InnoDB 是有序，解决 v4 随机写的痛点，适合分布式。
❌ 自增 ID 不能用于分布式
MySQL 原生自增多库会冲突；但可以设置不同自增步长，或者业务层引入 ID 生成器，依然可以使用数字 ID。
选型决策建议
单库业务，内部主键，不对外暴露 → BIGINT 自增 ID（首选）
多库合并、应用层预生成 ID、对外暴露主键 → UUID v7
分布式高并发，追求数字 ID，存储小 → 雪花算法 / 号段模式（64 位 long）
尽量避免：UUID v4 直接当 InnoDB 主键
对外接口小技巧
无论内部主键是自增 ID 还是 UUID，最佳实践：内部主键和对外业务 ID 分离。数据库用自增 / 雪花做主键，对外 API 返回单独的业务编码，兼顾性能和安全。
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢