高并发下 Guid.NewGuid()
的性能和排序问题
在 .NET 中直接调用
Guid.NewGuid()生成 ID，看似简单，但实际在高并发写入场景（如订单、日志、消息）中会暴露两个硬伤：一是性能开销大（每次调用涉及 RNGCryptoServiceProvider 或 OS 级随机数生成），二是生成的 GUID 是无序的，导致数据库主键插入时频繁触发 B+ 树页分裂，写入吞吐明显下降。
实测在 5000 QPS 持续写入 SQL Server 场景下，
Guid.NewGuid()相比有序 GUID（如
Guid.CreateSequential()）或雪花 ID，插入延迟高 3–5 倍，索引碎片率在 1 小时内升至 60%+。 避免用
Guid.NewGuid()作聚集索引主键，尤其在 SQL Server / PostgreSQL 中 若必须用 GUID，优先选
Guid.CreateSequential()（.NET 6+），它按时间前缀生成，局部有序 注意：即使顺序 GUID，在跨服务器部署时仍无法保证全局唯一时序，不适用于分库分表下的范围查询优化
.NET 原生不支持雪花算法，但可用 SnowflakeId
类库替代
C# 没有内置雪花 ID 生成器，需依赖第三方实现。目前较稳定的是
IdGen和
Twitter.Snowflake（已归档）的社区维护版，推荐使用
IdGen（NuGet 包
IdGen），它支持自定义 epoch、机器 ID 分配策略，并提供线程安全的
NextId()方法。
关键配置点：
IdGeneratorOptions中
MachineId必须全局唯一，建议从配置中心或环境变量注入，而非硬编码 默认 epoch 是 2020-01-01，若系统时间早于该值，
NextId()会抛
InvalidOperationException单机峰值约 4096 ID/毫秒（因序列号占 12 bit），超出会阻塞等待下一毫秒——这点在突发流量下需监控
WaitTimeMs指标
var options = new IdGeneratorOptions
{
MachineId = 1,
Epoch = new DateTime(2020, 1, 1, 0, 0, 0, DateTimeKind.Utc)
};
var idGen = new IdGenerator(options);
long id = idGen.NextId(); // 返回 long，非字符串GUID vs 雪花 ID：选型取决于数据分布与运维能力
不是“谁更好”，而是“谁更适配你的约束”。真实系统里常混合使用：
需要跨语言、跨存储（如 MongoDB + Redis + Kafka）且不关心排序？用Guid（转成字符串存，或用
byte[16]存二进制） 核心业务表（如订单、用户）要求高写入吞吐、范围查询、分页性能？选雪花 ID（
long类型，索引紧凑，B+ 树深度浅） 已有系统用 GUID 主键且无法重构？可加
CREATE INDEX IX_Order_CreatedTime ON Orders(CreatedTime) INCLUDE (Id)缓解查询压力 容器化部署时，
MachineId易重复（如 K8s Pod 重建），需配合 ZooKeeper / Etcd 实现动态注册，否则 ID 冲突风险上升
容易被忽略的边界：时钟回拨与分布式唯一性验证
雪花 ID 最脆弱的环节是服务器时钟回拨。哪怕回拨 1ms，
IdGen默认会抛异常（防止重复 ID），但生产环境往往选择“等待回拨恢复”策略，这会导致 ID 生成卡住。
更隐蔽的问题是：ID 全局唯一 ≠ 业务唯一。例如订单服务生成雪花 ID 后，若下游库存服务因重试重复消费，仍可能创建两条相同业务含义的记录——ID 唯一性不能替代业务幂等设计。
不要依赖雪花 ID 的“时间戳部分”做精确时间解析（受时区、精度截断影响） 在微服务间传递 ID 时，始终用long类型传输，避免 JSON 序列化为科学计数法（如
1234567890123456789变成
1.2345678901234567e+18） 若用 Dapper 查询，确保参数类型为
long，而非
int或
string，否则可能触发隐式转换导致索引失效
