Snowflake ID 不保证全局严格递增，仅单机内趋势递增，因时间回拨、workerId冲突或sequence重置导致MySQL中ORDER BY id DESC漏数据，需配合created_at字段及联合索引使用。
为什么直接用 SnowflakeId 生成的 ID 在 MySQL 中可能“不严格递增”
很多人以为 Snowflake ID 天然适合 MySQL 的自增主键替代方案，结果上线后发现 ORDER BY id DESC 查最新数据时漏掉几条——不是数据库问题，是时间回拨 + 机器 ID 分配混乱导致序列局部乱序。Snowflake 本身只保证「单机内趋势递增」，不保证全局严格单调。尤其在容器动态调度、K8s Pod 重启、NTP 校时等场景下，timestamp 回退或 sequence 重置会直接破坏顺序性。
实操建议：
- 避免把
SnowflakeId当作 MySQL 的AUTO_INCREMENT等价物；如需按时间倒序查，必须加created_at字段并建联合索引（(created_at, id)） - 用
workerId时别硬编码，推荐从配置中心或 Consul 获取，防止多实例部署时重复 - 若用
Microsoft.Extensions.DependencyInjection注册生成器，记得设为Singleton，否则每次 new 都会重置sequence
ULID 在 C# 中怎么落地：别只装 ULID NuGet 包就完事
ULID（Universally Unique Lexicographically Sortable Identifier）比 UUID 更适合做数据库主键，但 .NET 官方没原生支持，社区包质量参差不齐。最常用的是 RobThree/ULID，但它默认生成的是 128-bit 二进制格式（byte[]），直接转字符串是 Base32 编码，长度 26 位——而很多老系统字段只预留了 32 位 VARCHAR，这没问题；但如果你把它当 Guid 用（比如 EF Core 映射成 Guid 类型），运行时直接抛 InvalidCastException。
实操建议：
- 生成后立刻调用
.ToString()得到可存储的字符串，不要试图塞进Guid或long - EF Core 中对应字段类型必须是
string，且显式指定列类型：modelBuilder.Entity<t>().Property(e => e.Id).HasColumnType("varchar(26)")</t> - 如果需要兼容旧版 SQL Server（
datetime精度只有 3.33ms），注意 ULID 时间戳精度是毫秒级，不会出错；但若业务依赖「同一毫秒内生成多个 ID 的字典序」，得确认数据库排序规则是否区分大小写（ULID 使用 Base32，含数字和大写字母）
什么时候该选 Snowflake，什么时候该切 ULID
没有银弹。Snowflake ID 是 64 位整数，天然支持 long 运算、索引紧凑、MySQL 查询快；ULID 是字符串，占空间大、索引体积高，但完全去中心化、无需配置 workerId、无时间回拨风险、字符串本身可直接排序。
选型依据：
- 用 MySQL / PostgreSQL 且对写入吞吐要求极高（>5w QPS），优先
Snowflake；但得配套运维时间同步、workerId 分配机制 - 微服务跨语言（Go/Python/Java 都要生成 ID），选
ULID——各语言实现行为一致，不用协调中心节点 - 日志、事件溯源类场景，ID 要求人类可读、可大致判断时间（如
01HJ2XQZ7Z...开头能看出是 2024 年），ULID更友好 - 已有系统用
Guid.NewGuid()，想平滑过渡到有序 ID，ULID字符串长度接近（32 → 26），字段变更成本最低
C# 实现一个最小可用的 Snowflake 生成器要注意什么
网上抄来的 SnowflakeId 类常忽略线程安全和边界校验，上线后某天凌晨突然生成重复 ID。核心是 sequence 计数器必须原子递增，且每毫秒用完后要阻塞等待下一毫秒，不能溢出还硬加。
关键代码逻辑（非完整类，仅标重点）：
private long _lastTimestamp = -1L;
private long _sequence = 0L;
private readonly long _workerId;
private const long Twepoch = 1288834974657L; // 基准时间
private const int SequenceBits = 12;
private readonly long _maxSequence = ~(-1L << SequenceBits); // 4095
<p>public long NextId()
{
var timestamp = CurrentTimeMillis();
if (timestamp < _lastTimestamp) throw new Exception($"Clock moved backwards: {_lastTimestamp} > {timestamp}");</p><pre class="brush:php;toolbar:false;">if (_lastTimestamp == timestamp)
{
_sequence = (_sequence + 1) & _maxSequence;
if (_sequence == 0) timestamp = TilNextMillis(_lastTimestamp); // 阻塞
}
else
{
_sequence = 0L;
}
_lastTimestamp = timestamp;
return ((timestamp - Twepoch) << TimestampLeftShift) |
(_workerId << WorkerIdLeftShift) |
_sequence;}
容易被忽略的点：
-
TilNextMillis必须用while (CurrentTimeMillis() ，不能用 <code>Thread.Sleep，否则可能睡过头 -
_workerId和_datacenterId如果合用一个字段（常见简化版），总位宽不能超 10 位，否则会挤占sequence空间 - 测试时别用
DateTime.Now模拟时间，要用Stopwatch或注入时间提供器，否则单元测试跑不稳
C# 做分布式 ID，最难的从来不是算法本身，而是把时间、机器标识、序列三者在真实部署环境里对齐。本地跑通 100 万次不重复，不等于 K8s 里三个副本同时扩容时不撞车。
