不能直接用 AUTO_INCREMENT 做全局唯一 ID，因其在分库分表或微服务下会重复，且不满足时间序、可读性、防业务量暴露等要求；推荐 Snowflake 变体（如 leaf/tinyid）+ 数据库双写兜底。
为什么不能直接用 AUTO_INCREMENT 做全局唯一 ID
单库单表时 AUTO_INCREMENT 没问题，但一上分库分表或微服务架构，ID 就会重复。比如两个 MySQL 实例各自从 1 开始自增，插入同一条业务记录就可能产生冲突的 id=1。更麻烦的是，某些场景（如订单号、支付流水号）要求 ID 具备时间序、可读性、不暴露业务量，AUTO_INCREMENT 完全不满足。
常见错误现象：Duplicate entry '12345' for key 'PRIMARY' —— 多个写入节点同时生成相同 ID 导致主键冲突。
实际使用中要注意：
- 不要把数据库自增 ID 当作对外暴露的业务 ID
- 避免用 UUID（字符串太长、无序、索引效率差）直接当主键
- 跨机房部署时，必须考虑时钟回拨、网络分区对 ID 生成器的影响
推荐方案：Snowflake 变体 + 数据库双写兜底
Snowflake（64 位整数）是目前最平衡的选择：高位存时间戳，中间存机器 ID，低位存序列号。它能保证毫秒级唯一、趋势递增、长度可控（比 UUID 省一半存储和索引空间）。
但直接用 Twitter 原版 Snowflake 在 MySQL 场景下有坑：
-
workerId需手动配置，K8s 环境下 Pod 重启后容易重复 - 纯内存序列号在服务崩溃时可能丢号或重复（依赖本地时钟+计数器）
- MySQL 的
BIGINT UNSIGNED支持 0–18446744073709551615，原版 Snowflake 最高位是符号位，需改造为无符号版本
实操建议：
一个经过完善设计的经典网上购物系统，适用于各种服务器环境的高效网上购物系统解决方案，shopxp购物系统Html版是我们首次推出的免费购物系统源码，完整可用。我们的系统是免费的不需要购买，该系统经过全面测试完整可用，如果碰到问题，先检查一下本地的配置或到官方网站提交问题求助。 网站管理地址：http://你的网址/admin/login.asp 用户名：admin 密 码：admin 提示：如果您
- 用
leaf（美团开源）或tinyid（百度）这类带 DB 存储max_id的 Snowflake 变体，避免人工维护workerId - 数据库表里仍保留
id BIGINT UNSIGNED NOT NULL PRIMARY KEY，但不再依赖AUTO_INCREMENT - 生成 ID 后，先
INSERT ... ON DUPLICATE KEY UPDATE写入一张id_generator表做幂等校验，再用于业务表
如何在 INSERT 语句里安全嵌入生成的 ID
不能靠触发器或存储过程动态生成 ID，因为分布式环境下无法保证事务一致性。正确做法是在应用层生成 ID，再作为参数传入 SQL。
例如用 MyBatis 插入订单：
INSERT INTO `order` (id, user_id, amount, created_at) VALUES (#{id}, #{userId}, #{amount}, NOW())
关键点：
-
#{id}必须由应用层调用 ID 生成器得到，不是数据库返回值 - 如果用 JPA/Hibernate，禁用
@GeneratedValue(strategy = GenerationType.IDENTITY)，改用@GeneratedValue(strategy = GenerationType.NONE)+ 手动赋值 - 批量插入时，每个记录的 ID 必须独立生成，不能复用同一个 ID 或简单递增（否则破坏分布式唯一性）
备份与迁移时 ID 连续性是否重要
不重要，而且刻意追求连续反而危险。连续 ID 容易被爬虫遍历、暴露业务规模、导致热点分片（比如所有新订单都落到最新分片）。真正的“全局唯一”只要求不重复、可排序、低冲突，不要求数学连续。
容易被忽略的点：
- 历史数据导入时，若旧系统用
AUTO_INCREMENT，新系统用 Snowflake，ID 类型混用会导致 JOIN 失败或排序错乱 —— 必须统一为BIGINT UNSIGNED并预留足够位宽 - 从 MySQL 迁移到 TiDB 或 OceanBase 时，部分分布式数据库自带
auto_random，但只适用于单集群，跨数据中心仍需外部 ID 生成器 - 审计日志或消息队列中记录的 ID，一旦生成就不能修改，哪怕后续发现重复也应走补偿流程，而非重发
