改用uuid或雪花算法能绕过自增锁争用，因其将id生成完全移出mysql，写入时直接提供确定值，innodb无需触发auto_increment逻辑，自然避免自增锁。
为什么改用UUID或雪花算法能绕过自增锁争用
自增锁争用本质是InnoDB对AUTO_INCREMENT值分配过程的串行化控制，只要还在用数据库生成主键，就绕不开innodb_autoinc_lock_mode的取舍——要么牺牲连续性（mode=2），要么牺牲并发（mode=1/0）。而UUID或雪花算法把ID生成完全移出MySQL，写入时直接提供确定值，InnoDB只需做普通插入，不触发自增逻辑，自然没有自增锁这回事。
UUID在MySQL中实际落地要注意什么
直接用UUID()函数或应用层生成CHAR(36)字符串，看似简单，但有硬伤：
- 索引膨胀：36字节比
INT（4字节）或BIGINT（8字节）大得多，二级索引会连带放大，内存和磁盘开销显著上升 - 写入随机性：UUID是无序的，频繁插入会导致B+树页分裂加剧，IOPS压力变大
- 不建议用
UUID_SHORT()：它依赖服务器启动时间+server_id+计数器，集群多实例下仍可能冲突，且不是标准UUID - 若必须用UUID，优先选
BINARY(16)存UNHEX(REPLACE(UUID(), '-', ''))，节省一半空间
雪花算法接入MySQL前必须确认的三件事
雪花算法（如Twitter Snowflake或其变种）生成的是64位整数，趋势递增、全局唯一，但不是“即插即用”：
- 确保所有服务实例的
workerId配置不重复：同一机房内不同机器、容器或K8s Pod必须分配唯一ID，否则必然冲突 - 注意时钟回拨：服务所在机器时间倒退会导致ID重复，生产环境必须部署NTP校时，或选用带回拨容错的SDK（如百度UidGenerator）
- MySQL字段类型要匹配：必须用
BIGINT UNSIGNED，不能用INT或带符号BIGINT，否则超范围会溢出或转负
切换过程中最容易被忽略的外键和分页逻辑
很多团队只盯着主键替换，却忘了业务代码里埋着的隐式依赖：
- 分页查询写成
WHERE id > ? ORDER BY id LIMIT 100：雪花ID虽趋势递增，但同一毫秒内多个ID顺序与插入顺序无关，分页结果可能漏数据或重复 - 外键关联表仍用自增ID：比如订单表切了雪花ID，但订单项表还用
order_id INT AUTO_INCREMENT，关联时类型不匹配、索引失效 - 运维脚本硬编码
MAX(id) + 1逻辑：备份恢复、数据迁移工具里这类假设必须全部清理，否则会生成错误ID
真正难的不是生成ID，而是让整个数据链路接受“ID不再由数据库兜底”这个事实——从建表语句、ORM映射、SQL审核规则到DBA监控脚本，都得同步更新。
