guid作为聚簇索引会导致页分裂和高碎片，因其随机性使插入位置不可预测，引发频繁页分裂与i/o开销；newsequentialid()仅单机递增、重启重置、跨节点不保序，且16字节宽度加剧非聚集索引膨胀；推荐用int identity作聚簇键、guid作逻辑主键并建唯一非聚集索引。
为什么 GUID 作为聚簇索引会导致页分裂和高碎片
因为 SQL Server 的聚簇索引直接决定数据行的物理存储顺序，而 NEWID() 生成的 GUID 是完全随机的十六进制值（如 'E8F1A9B2-3C4D-5E6F-7A8B-9C0D1E2F3A4B'），每次插入都可能落在现有数据页的任意位置。数据库必须把目标页从磁盘读入内存、找到插入点、挪动已有记录腾出空间——如果页已满，还要触发页分裂：原页拆成两页，约一半数据被复制到新页，并更新父节点指针。这个过程带来大量额外 I/O 和锁争用。
NEWSEQUENTIALID() 真的能解决插入性能问题吗
它能在单台服务器上生成近似递增的 GUID，比如连续调用几次得到：'A0000000-0000-0000-0000-000000000001'、'A0000000-0000-0000-0000-000000000002'……但要注意：
-
NEWSEQUENTIALID()只能用作列的DEFAULT约束，不能在SELECT或INSERT ... VALUES中直接调用 - 重启 SQL Server 服务后，序列会重置（不是全局连续，只是“本机本次会话内递增”）
- 多实例或集群环境下，不同节点生成的值仍可能交叉，无法保证跨服务器单调递增
- 即使递增，16 字节的宽度仍比
INT（4 字节）或BIGINT（8 字节）大得多，导致非聚集索引体积膨胀
聚簇索引键变大对非聚集索引的实际影响
SQL Server 每个非聚集索引的叶节点都隐式包含聚簇索引键值（用于回表定位数据行）。如果你用 UNIQUEIDENTIFIER 做聚簇键，那么每条非聚集索引记录都要多存 16 字节。假设一张表有 100 万行、6 个非聚集索引，仅这部分冗余就多占约 1000000 × 6 × 16 = 96 MB 存储；更关键的是，这些额外字节会降低内存中索引页的缓存密度，增加逻辑读和物理读次数。
真正推荐的折中方案：分离逻辑主键与物理排序键
不要让 GUID 同时承担“唯一标识”和“物理排序”两个角色。典型做法是：
- 新增一个
ID INT IDENTITY(1,1)列，设为聚簇索引（保证插入高效、碎片低） - 保留
RowGuid UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID()列，设为主键（逻辑唯一约束），并加唯一非聚集索引 - 外键关联、分布式同步等场景继续用
RowGuid，查询走非聚集索引即可 - 如果必须用 GUID 聚簇（如迁移遗留系统），至少禁用自动统计更新、定期
REORGANIZE或REBUILD索引，并监控avg_fragmentation_in_percent
最常被忽略的一点：即便用了 NEWSEQUENTIALID()，只要表上有高频并发插入 + 非聚集索引更新，页闩（PAGELATCH_EX）争用依然可能出现——这不是 GUID 本身的问题，而是所有宽聚簇键在高并发下的共性瓶颈。
