引子

做过项目的同学都知道，给数据起个唯一的"身份证号"是个常见需求。比如用户注册、订单编号、日志记录等等，都需要保证每条数据都有个独一无二的标识。

以前可能直接用数据库的自增ID就完事了，但现在系统越来越复杂，分布式、微服务满天飞，简单的自增ID就不够用了。今天咱们就来聊聊C#里三种常用的唯一ID生成方案：GUID、UUID和ULID。

别被这些英文缩写吓到，其实都挺简单的。

什么是GUID？

GUID全称叫"全局唯一标识符"，说白了就是一个128位（16字节）的随机数，长得像这样：

f47ac10b-58cc-4372-a567-0e02b2c3d479

看起来挺唬人的，其实就是用连字符分割的一串十六进制数字。

GUID的特点

优点：

• 全球唯一，碰撞概率比中彩票还低
• .NET原生支持，用起来超简单
• 微软全家桶都认这个格式

缺点：

• 完全随机，没法排序
• 用作数据库主键时性能不太好（后面详细说）
• 看起来不够"人性化"

什么时候用GUID？

• 分布式系统需要生成唯一ID
• 微软技术栈项目
• 不需要排序的场景
• API接口的资源标识

什么是UUID？

UUID其实就是GUID的"国际标准版"，格式完全一样，只是叫法不同。就像可乐和百事可乐，本质上都是碳酸饮料。

UUID有好几个版本：

• UUID v1: 基于时间戳和MAC地址（可能泄露隐私）
• UUID v4: 完全随机（最常用）
• UUID v3/v5: 基于命名空间（可重现）

在.NET里，Guid.NewGuid()生成的就是UUID v4。

什么时候用UUID？

• 跨平台项目（Java、Python、Node.js都支持）
• 需要与其他系统对接
• 强调"标准化"的场景

什么是ULID？

ULID是个相对较新的东西，全称"通用唯一字典序可排序标识符"。听名字就知道，它最大的特点就是可排序。

ULID长这样：

01GZHT44KMWWT5V2Q4RQ6P8VWT

看起来比GUID简洁多了，没有连字符，而且都是大写字母和数字。

ULID的结构

ULID很聪明，它把时间戳放在了前面：

• 前10个字符：时间戳（毫秒级）
• 后16个字符：随机数

这样设计的好处是，按字符串排序就等于按时间排序，非常方便。

ULID的特点

优点：

• 天然按时间排序
• 比GUID短，更容易阅读
• 数据库性能好（顺序插入）
• 包含时间信息

缺点：

• .NET没有原生支持，需要第三方库
• 相对较新，生态不如GUID/UUID成熟

什么时候用ULID？

• 日志系统（需要按时间排序）
• 高并发写入场景
• 需要"人性化"ID的场景
• 对数据库性能要求高的项目

性能对比：数据库里的表现

这是个重点话题。很多同学可能不知道，用GUID做主键其实挺坑的。

为什么GUID/UUID性能不好？

想象一下，你有一本通讯录，按姓名排序。如果每次都往中间随机插入新联系人，你得不停地挪动其他条目，很麻烦对吧？

数据库索引也是这个道理。GUID是随机的，每次插入都可能在索引的中间位置，导致：

• 索引页分裂
• 大量数据移动
• 缓存命中率低
• 整体性能下降

ULID的优势

ULID因为前面是时间戳，新生成的ID总是比旧的大，所以总是插入在索引末尾，就像在通讯录最后加新人一样简单。

实际测试数据（以10万条插入为例）：

差距还是很明显的。

代码实战

生成GUID

// 最简单的方式
var guid = Guid.NewGuid();
Console.WriteLine($"GUID: {guid}");

// 转换为不同格式
Console.WriteLine($"无连字符: {guid:N}");
Console.WriteLine($"大括号: {guid:B}");
Console.WriteLine($"小括号: {guid:P}");

// 输出示例：
// GUID: f47ac10b-58cc-4372-a567-0e02b2c3d479
// 无连字符: f47ac10b58cc4372a5670e02b2c3d479
// 大括号: {f47ac10b-58cc-4372-a567-0e02b2c3d479}
// 小括号: (f47ac10b-58cc-4372-a567-0e02b2c3d479)

生成UUID

// 在.NET中，UUID就是GUID
var uuid = Guid.NewGuid();
Console.WriteLine($"UUID: {uuid}");

// 如果需要特定版本的UUID，可能需要第三方库
// 比如 UUIDNext 包

生成ULID

首先安装NuGet包：

dotnet add package Ulid

然后使用：

using System;

classProgram
{
    static void Main()
    {
        // 生成ULID
        var ulid = Ulid.NewUlid();
        Console.WriteLine($"ULID: {ulid}");
        
        // ULID可以转换为GUID
        var guid = ulid.ToGuid();
        Console.WriteLine($"转换为GUID: {guid}");
        
        // 也可以从时间戳生成ULID
        var timestamp = DateTimeOffset.UtcNow;
        var timedUlid = Ulid.NewUlid(timestamp);
        Console.WriteLine($"指定时间的ULID: {timedUlid}");
    }
}

实际项目中的选择建议

场景一：传统Web应用

如果你的项目比较传统，单体架构，用户量不是特别大：

• 推荐GUID：简单可靠，.NET原生支持
• 如果对性能要求高，考虑用自增ID + GUID的组合

场景二：分布式系统

多个服务需要生成唯一ID，不能依赖数据库自增：

• 推荐ULID：性能好，可排序，适合微服务
• 如果团队对新技术接受度不高，GUID也行

场景三：日志系统

需要按时间查询，写入频繁：

• 强烈推荐ULID：天生按时间排序，性能优秀

场景四：对外API

需要给外部系统提供资源标识：

• 推荐UUID：标准化，跨平台兼容性好

性能优化小贴士

如果必须用GUID做主键

1. **使用NEWSEQUENTIALID()**（SQL Server）

CREATE TABLE Users (
    Id UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY,
    Name NVARCHAR(100)
);

1. 考虑复合主键

public class Order
{
    public int SequenceId { get; set; }  // 自增，聚集索引
    public Guid OrderId { get; set; }    // GUID，对外暴露
    // 其他属性...
}

ULID的最佳实践

1. 统一时间源：分布式环境下确保各节点时间同步
2. 批量生成：一次生成多个ULID时使用同一时间戳
3. 合理缓存：避免频繁创建ULID生成器

总结

三种方案各有千秋：

• GUID/UUID：老牌劲旅，稳定可靠，适合大多数场景
• ULID：后起之秀，性能优秀，特别适合需要排序的场景

选择建议：

• 新项目优先考虑ULID
• 已有项目如果性能没问题，继续用GUID也行
• 对外接口推荐UUID（标准化）

最重要的是，不要为了用新技术而用新技术。根据实际需求选择最合适的方案，才是明智之举。

记住：没有银弹，只有最适合的解决方案。