雪花ID能从源头避免SQL并发插入主键冲突，因其是全局唯一、时间有序、无中心协调的64位整数，不依赖数据库自增或锁表；而自增主键在高并发下因写锁争抢易导致阻塞、重复或跳号，分布式环境更失效；雪花ID由时间戳、机器ID、序列号组成，只要机器ID唯一且时钟不回拨即绝对不冲突；应用层生成、无需DB参与、自带时序性、兼容主流数据库大整型；落地需注意机器ID全局唯一、时钟回拨兜底、字段类型必须用BIGINT或DECIMAL(20,0)；插入语句无需加锁或重试，冲突概率趋近于零。
用雪花ID（Snowflake ID）做主键，能从源头避免SQL并发插入时的主键冲突，关键在于它生成的是全局唯一、时间有序、无中心协调的64位整数，不依赖数据库自增或锁表。
为什么自增主键在并发下容易冲突
传统 AUTO_INCREMENT 依赖数据库写锁保证顺序，高并发插入时多个事务争抢同一自增值，轻则等待阻塞，重则因事务回滚或批量插入逻辑缺陷导致重复值或跳号；分布式环境下多个数据库实例更无法共享自增序列，直接失效。
雪花ID如何天然规避冲突
雪花ID由4部分组成：1位符号位（固定0）+ 41位毫秒时间戳 + 10位机器ID（含数据中心ID）+ 12位序列号。同一毫秒内，靠机器ID和序列号组合确保不重复；不同毫秒天然错开。只要机器ID不重复、时钟不回拨，就绝对不冲突。
- 无需数据库参与ID生成，应用层直接产出，彻底脱离DB锁
- 时间戳前置，ID本身自带时序性，适合做分库分表的路由键或查询排序
- 64位整数，兼容MySQL BIGINT、PostgreSQL BIGINT、Oracle NUMBER(19)等主流类型
落地时必须注意的3个细节
雪花ID不是“引入一个SDK就完事”，实际使用中这几个点常被忽略：
- 机器ID必须全局唯一：不能所有服务实例都用默认值0。建议通过配置中心分配，或结合K8s StatefulSet序号、Consul节点标签等方式动态生成
- 时钟回拨要兜底：如果服务器时间向后跳（如NTP校准），可能导致ID重复。生产环境需启用等待策略（如暂停生成直到追平时间）或降级为UUID
- 数据库字段类型要匹配：别用INT或UNSIGNED INT存雪花ID（最大只到42亿，而雪花ID可达9千亿），必须用BIGINT（有符号）或DECIMAL(20,0)
插入语句无需额外加锁或重试
因为ID已在应用层生成且唯一，SQL插入变成标准的单条写入：
INSERT INTO order (id, user_id, amount) VALUES (912345678901234567, 1001, 99.9);不用SELECT ... FOR UPDATE查是否存在，不用ON DUPLICATE KEY UPDATE，也不用REPLACE INTO。冲突概率趋近于零，吞吐量直接受益于去中心化ID生成。
