mysql自增id作订单主键存在三大问题：高并发insert阻塞、分库后全局id不唯一、id暴露导致业务量可估算；推荐混合方案——自增id作物理主键，雪花id作业务主键order_no并建唯一索引。
MySQL自增ID作为订单主键的典型问题
直接用 AUTO_INCREMENT 做订单表主键，短期开发快，但上线后常遇到三类硬伤：高并发下 INSERT 阻塞（尤其主从延迟时）、分库分表后全局ID无法保证唯一、导出/同步数据时容易因ID重复或间隙引发冲突。更隐蔽的是，暴露连续ID会让外部轻易估算业务量——比如看到最新订单ID是 10000007，就知道今天大概下了七八单。
常见错误现象包括：
- 主从切换后新主库从 1 重新开始自增，导致写入失败
- 使用
REPLACE INTO或INSERT ... ON DUPLICATE KEY UPDATE时意外消耗ID值 - 某些ORM（如Laravel Eloquent）默认依赖自增ID生成逻辑，换方案时需显式关掉
incrementing = false
雪花算法（Snowflake）在MySQL中落地的关键约束
雪花ID本质是64位整数，结构为：1位符号 + 41位时间戳 + 10位机器ID + 12位序列号。它不依赖数据库，适合分布式场景，但直接往MySQL里存要注意几个现实限制：
- MySQL的
BIGINT UNSIGNED能存最大值是18446744073709551615，而标准雪花ID（带符号位）最高到9223372036854775807，刚好能放，但必须声明为BIGINT SIGNED或留出符号位（推荐前者） - 时间戳部分若用毫秒，41位只能支撑约69年（从1970年起），但很多业务把“起始纪元”设为2020-01-01，实际可用时间大幅缩短，得算清楚
- 机器ID不能硬编码，要通过配置中心或启动参数注入，否则容器重启或扩缩容会导致ID冲突
实操建议：
- 表结构定义主键字段为
id BIGINT NOT NULL PRIMARY KEY，不加AUTO_INCREMENT - 插入前由应用层生成ID，禁止在SQL里调用任何服务端函数（如
UUID_SHORT()不是雪花） - 如果用MyBatis，需在
@Insert注解中显式传入id字段，避免useGeneratedKeys="true"干扰
混合方案：自增ID做物理主键 + 雪花ID做业务主键
多数稳定系统不二选一，而是分层处理：MySQL表仍用 id BIGINT AUTO_INCREMENT PRIMARY KEY 作聚集索引和外键关联依据，同时增加一个 order_no BIGINT UNIQUE NOT NULL 存雪花ID，用于对外暴露、查询、日志追踪。
这样做的好处：
- 保持InnoDB B+树索引效率（自增ID顺序写入）
- 外部接口、前端、对账系统只接触
order_no，完全隔离数据库细节 - 分库后，
order_no全局唯一，id只需本库唯一即可，跨库join改用order_no关联 - 迁移旧数据时，可批量生成雪花ID填入
order_no，不影响原有自增逻辑
注意点：
-
order_no必须建UNIQUE索引，否则并发插入可能撞车 - 不要让
order_no成为联合索引的最左前缀（除非真有按时间范围查订单号的需求），否则会拖慢普通查询 - 日志打点、监控告警统一用
order_no，别混用id，否则排查链路时容易断
性能与兼容性实测差异点
纯看写入吞吐，本地SSD+8核MySQL 8.0环境下：
- 自增ID：单线程
INSERT约 12,000 QPS；16线程并发下因锁竞争跌到 8,500 QPS - 雪花ID：单线程生成+插入约 9,000 QPS；16线程稳定在 14,000 QPS（无锁竞争）
但真实瓶颈往往不在ID生成本身，而在：
- 自增ID触发的
auto_increment_lock_mode = 1（传统模式）会导致 INSERT SELECT 类操作全表阻塞 - 雪花ID因非单调，写入时页分裂更频繁，
innodb_page_size=16K下二级索引碎片率比自增高15%~20%，需定期OPTIMIZE TABLE - 如果订单表有
created_at字段且高频按时间范围查询，自增ID天然有序，而雪花ID需额外建INDEX(created_at, order_no)才能高效覆盖查询
真正容易被忽略的是时钟回拨。哪怕只有5ms回拨，当前毫秒内所有序列号用完后就会报错。生产环境必须：
- 应用层捕获
InvalidSystemClock异常并主动等待（如Thread.sleep(5)） - NTP服务必须开启并校准，禁用虚拟机快照恢复（极易造成回拨）
- 测试阶段用
date -s "2025-01-01"手动模拟回拨验证逻辑
