SQL Server 主键选取策略：自动增长、GUID、手动与 COMB 类型对比

主键策略的核心目标与常见选型

主键的主要作用是唯一标识一行记录，确保更新和删除操作的准确性，并常作为外键构成参照完整性约束。常见的 SQL Server 主键选取方式包括：自动增长字段 (IDENTITY)、手动增长字段、UniqueIdentifier (GUID) 以及 COMB (Combine) 类型。每种策略在开发便利性、系统性能和数据一致性之间各有侧重。

一、自动增长型字段 (IDENTITY)

第1步：理解自动增长的工作机制

自动增长字段由数据库系统在插入记录时自动分配唯一值，开发者无需在应用层处理键值生成，极大简化了开发流程。在 SQL Server 中，可通过全局变量 @@IDENTITY 获取刚插入记录的自增值。

第2步：分析潜在缺陷与事务矛盾

尽管使用简便，但在复杂业务场景下存在显著问题：

• 网络往返增加： 当主表与明细表需要通过事务同时更新时，若主表 ID 为自增，客户端必须先提交主表以获取 @@IDENTITY，再更新明细表，最后提交事务。这增加了网络 Round-Trip 次数，降低并发性能。
• 多库同步冲突： 在使用 SQL Server 分发/订阅进行数据复制时，不同服务器的自增种子可能导致合并后的主键冲突。

优化建议： 若在 ADO.NET 中使用 DataSet 模拟自增，应将初始值和增量设为 -1 以避免误解；利用 DataRelation 的级联功能可部分缓解两表更新时的键值传递麻烦。

二、手动增长型字段

第1步：建立键值维护表

手动增长要求应用程序或数据库逻辑自行维护当前最大键值。通常创建一个单独的键值表（如 IntKey），包含 KeyName 和 KeyValue 字段。

第2步：编写获取并递增键值的存储过程

通过 SQL 存储过程原子性地读取并递增键值，确保多线程并发下的唯一性。代码如下：

CREATE PROCEDURE [GetKey]
@KeyName char(10), 
@KeyValue int OUTPUT
AS
UPDATE IntKey SET @KeyValue = KeyValue = KeyValue + 1 WHERE KeyName = @KeyName
GO

第3步：评估性能负载

此方法解决了多库合并冲突问题（通过分配不同的取值段），但每次获取新键值都需访问数据库，增加了网络和 I/O 负载。在低网速或离线环境下表现较差，且需额外处理并发锁问题，系统复杂度较高。

三、UniqueIdentifier (GUID)

第1步：在客户端生成全局唯一标识

SQL Server 提供 NEWID() 函数，.NET/C# 中可通过 System.Guid.NewGuid() 生成。GUID 占用 16 字节，重复概率极低，且完全在客户端生成，无需网络交互获取键值，完美解决上述两类策略的网络往返问题。

C# 生成示例：

Guid u = System.Guid.NewGuid();

第2步：识别索引性能瓶颈

尽管避免了网络延迟，GUID 存在严重性能隐患：
1. 存储空间大： 是整数 (4字节) 的 4 倍，占用大量磁盘与内存。
2. 索引碎片化： GUID 无序，导致非聚集索引频繁分裂，检索、插入和更新速度远低于整数主键。实验数据显示其性能显著落后于 INT 类型。

四、使用“COMB (Combine)”类型优化

第1步：理解 COMB 的设计原理

COMB 类型旨在结合 GUID 的全局唯一性与时间有序性。其核心思路是将 GUID 的后 6 字节替换为生成的时间戳（精确到 1/300 秒，匹配 SQL Server 精度），前 10 字节保留原始 GUID 部分。这样既保持了唯一性，又使得数据在插入时大致有序，大幅降低索引碎片。

第2步：在 SQL Server 中生成 COMB

可以通过 T-SQL 将 NewID() 的结果与当前日期时间的二进制组合，强制转换回 UniqueIdentifier 格式：

DECLARE @aGuid UNIQUEIDENTIFIER
SET @aGuid = CAST(CAST(NEWID() AS BINARY(10)) 
+ CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER)

第3步：在 C# 中实现 COMB 生成与解析

在应用层生成 COMB 可以避免数据库开销。以下 C# 代码实现了 COMB 的生成及从 GUID 中提取时间的功能：

//================================================================
/// <summary>
/// 返回 GUID 用于数据库操作，特定的时间代码可以提高检索效率
/// </summary>
public static Guid NewComb()
{
    byte[] guidArray = System.Guid.NewGuid().ToByteArray();
    DateTime baseDate = new DateTime(1900,1,1);
    DateTime now = DateTime.Now;
    TimeSpan days = new TimeSpan(now.Ticks - baseDate.Ticks);
    TimeSpan msecs = new TimeSpan(now.Ticks - (new DateTime(now.Year, now.Month, now.Day).Ticks));
    
    byte[] daysArray = BitConverter.GetBytes(days.Days);
    byte[] msecsArray = BitConverter.GetBytes((long)(msecs.TotalMilliseconds/3.333333));
    
    // Reverse the bytes to match SQL Servers ordering
    Array.Reverse(daysArray); 
    Array.Reverse(msecsArray); 
    
    // Copy the bytes into the guid at the end
    Array.Copy(daysArray, daysArray.Length - 2, guidArray, guidArray.Length - 6, 2);
    Array.Copy(msecsArray, msecsArray.Length - 4, guidArray, guidArray.Length - 4, 4);
    
    return new System.Guid(guidArray);
}

//================================================================
/// <summary>
/// 从 SQL SERVER 返回的 GUID 中生成时间信息
/// </summary>
public static DateTime GetDateFromComb(System.Guid guid)
{
    DateTime baseDate = new DateTime(1900,1,1);
    byte[] daysArray = new byte[4];
    byte[] msecsArray = new byte[4];
    byte[] guidArray = guid.ToByteArray();
    
    Array.Copy(guidArray, guidArray.Length - 6, daysArray, 2, 2);
    Array.Copy(guidArray, guidArray.Length - 4, msecsArray, 0, 4);
    
    Array.Reverse(daysArray); 
    Array.Reverse(msecsArray); 
    
    int days = BitConverter.ToInt32(daysArray, 0);
    int msecs = BitConverter.ToInt32(msecsArray, 0);
    
    DateTime date = baseDate.AddDays(days);
    date = date.AddMilliseconds(msecs * 3.333333);
    return date;
}

经过测试，COMB 类型的性能虽略慢于纯 INT 主键，但远优于标准 UniqueIdentifier，是在分布式环境和高并发写入场景下的极佳平衡点。

简要总结

主键的选择直接决定系统的扩展性与响应速度。若仅单机使用且对性能极致敏感，可选用 INT IDENTITY；若涉及离线数据同步或多库架构，推荐使用基于 C# 实现的 COMB 类型以提升索引效率并保持全局唯一性；避免在无必要情况下直接使用无序的 GUID。以上就是 SQL Server 数据库主键选取策略的详细内容，更多关于 SQL 设计与优化的资料请关注本站其它相关文章！