数据库表的主键设计会直接影响写入性能，而C#项目里常见的Guid.NewGuid虽然能生成全局唯一值，却因为完全无序给数据库索引带来持续压力。要理解这个问题，需要先看聚集索引如何组织数据，以及随机值为什么比顺序值代价更高。
一、随机Guid为什么拖慢数据库写入
在SQL Server、MySQL InnoDB等常见关系型数据库中，主键通常同时是聚集索引键。聚集索引并不是一份单独的目录，而是数据页本身按照主键值的顺序物理组织。插入一行新数据时，数据库会根据主键值找到它应该落入的数据页。如果主键是自增整数，新主键几乎总是大于已有值，写入集中在最后一个数据页，追加成本很低。如果主键是Guid.NewGuid产生的随机值，新值可能落在任意位置。
当目标数据页没有剩余空间时，数据库会发生页分裂。例如一个页已经存满100行，而新的Guid恰好排在中间，数据库会申请一个新页，把大约一半数据搬过去，再把新行插入，并更新索引指针。频繁的页分裂带来三重成本：写入时CPU和日志量增加、数据页空间利用率下降、索引碎片增多导致范围查询变慢。这也解释了为什么很多系统在上线初期表现正常，随着数据量增长，随机Guid主键表的插入TPS会逐渐下降。
可以用一个简单SQL查询观察碎片情况。在SQL Server中，如果主键是随机Guid，新建表并插入几十万行后，sys.dm_db_index_physical_stats返回的avg_fragmentation_in_percent通常会很高，而顺序主键表则低得多。下面是一段示例查询：
SELECT
OBJECT_NAME(ps.object_id) AS table_name,
ix.name AS index_name,
ps.avg_fragmentation_in_percent,
ps.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('dbo.Orders'), NULL, NULL, 'LIMITED') AS ps
JOIN sys.indexes AS ix
ON ps.object_id = ix.object_id
AND ps.index_id = ix.index_id
WHERE ix.name IS NOT NULL;
二、C#中生成有序UUID的几种方法
要让主键重新拥有顺序性，同时保留Guid的全局唯一优势，可以生成有序UUID。目前C#项目主要有三种做法：使用SQL Server提供的顺序标识、使用新版.NET平台提供的标准时间有序Guid，以及自己实现COMB算法。
第一种做法是使用SQL Server的NEWSEQUENTIALID。它只能在表定义中作为默认值使用，不能像NEWID那样在任意SQL语句中直接调用。它的优点是数据库内部生成的顺序性最符合SQL Server对uniqueidentifier的排序规则，缺点是强绑定SQL Server，而且插入前拿不到值。对于ORM或业务层需要提前构造主键的场景，通常不太方便。
第二种做法是使用新版.NET提供的时间有序Guid接口，例如Guid.CreateVersion7。UUID v7把时间戳放在高位，整体趋势随时间递增，属于跨语言标准。新系统如果运行时支持这个接口，可以直接采用，避免自己维护字节顺序。老环境或需要兼容其他框架时，仍然需要自己实现。
第三种做法是自己实现COMB算法，核心思路是保留Guid的大部分随机字节保证唯一性，同时把当前时间戳覆盖到Guid的前几个字节，使生成结果随时间大体递增。下面是一个基础实现：
public static class SequentialGuid
{
private static readonly object Sync = new();
public static Guid NewSequentialGuid()
{
byte[] guidBytes = Guid.NewGuid().ToByteArray();
long timestamp = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds();
byte[] timestampBytes = BitConverter.GetBytes(timestamp);
if (BitConverter.IsLittleEndian)
{
Array.Reverse(timestampBytes);
}
lock (Sync)
{
// 用时间戳覆盖Guid前6个字节，使整体趋势随当前时间递增
Array.Copy(timestampBytes, 2, guidBytes, 0, 6);
}
return new Guid(guidBytes);
}
}
这个实现保证单机上生成的Guid大体按时间递增。如果同一毫秒内出现大量并发写入，随机部分仍能避免主键冲突，但顺序性可能略有波动。对顺序要求非常严格的系统，可以在时间戳之外再拼接自增计数，或者直接使用数据库端生成的顺序主键。
三、不同数据库对UUID排序规则的差异
有序UUID并不是简单地把时间戳放在Guid字节开头就能在所有数据库中表现一致。SQL Server对uniqueidentifier的排序比较特殊，它并不完全按照字符串顺序，而是混合字节序，前4字节会被当作整数处理。这意味着在.NET中生成的Guid，如果直接写成时间戳在前的字节数组，SQL Server排序时仍可能表现为乱序。为了让有序Guid在SQL Server中真正有序，通常需要把时间戳前4字节按大端方式重新排列。
PostgreSQL的uuid类型按16字节的原始字节序比较，应用层生成的时间戳前置Guid可以直接获得较好的顺序性。MySQL通常用char(36)或binary(16)存储UUID，如果使用char(36)，排序由字符顺序决定，建议统一使用binary(16)并写入有序字节，否则排序效果会打折扣。所以在实现COMB之前，最好先用小批量数据验证目标数据库的真实排序结果，而不是只看字符串显示值。
另外，不同的ORM和数据库驱动对Guid的读写也可能存在大小端转换。例如读取binary(16)字段映射到C# Guid时，驱动是否原样复制字节、是否反转前4字节，都会影响顺序性。遇到顺序不符合预期时，可以从字节布局入手检查，而不是盲目更换算法。
四、性能验证与落地建议
在正式替换主键生成方式之前，建议先做一个小型压测。创建两张结构相同的表，一张使用随机Guid主键，另一张使用有序Guid主键，分别插入二十万行数据，观察执行时间和索引碎片。下面代码可以生成两组用于压测的主键列表：
List<Guid> randomIds = new List<Guid>();
List<Guid> sequentialIds = new List<Guid>();
for (int i = 0; i < 200000; i++)
{
randomIds.Add(Guid.NewGuid());
sequentialIds.Add(SequentialGuid.NewSequentialGuid());
}
插入完成后，再使用前面提到的sys.dm_db_index_physical_stats查询两张表的碎片率。通常随机Guid表的avg_fragmentation_in_percent会明显更高，page_count也更多，因为页分裂制造了大量半空页。随着插入量增加，这种差距会进一步拉大，写入延迟也会更不稳定。
落地时还要分清场景。如果表数据量很小、写入频率很低，或者主键并不是聚集索引，随机Guid的影响有限，不一定需要改动。如果表已经使用随机Guid作为主键并且数据量很大，改成有序Guid并不能让历史数据自动变得有序，通常需要新建表、迁移数据、再切换。此外，有序Guid只解决主键写入和范围扫描问题，二级索引仍然会记录主键值，因此对二级索引的维护成本不会完全消失，只是相比随机主键更可控。
综合来看，C#项目中如果主键使用Guid，且数据库写入性能比较敏感，引入有序UUID是一种成本适中、收益明显的优化。优先考虑数据库或运行时提供的标准顺序标识，其次才是自定义COMB实现。关键是理解目标库对Guid的排序规则，并用压测数据和碎片指标验证优化效果，而不是简单换一个生成函数就结束。
