GUID设为PK还是仅作索引？客户端生成标识符方案咨询

方案1（GUID非聚集主键 + 自增聚集列）的核心优势 #

• 后台查询性能更优：自增整数的聚集索引是有序的，后台进行关联查询（多表JOIN、时间范围筛选等操作）时，数据库可借助有序索引快速定位数据，相比随机分布的GUID索引，能大幅减少IO开销。同时有序写入不会频繁触发数据页分裂，写入性能也更稳定。
• 内部运维更便捷：自增短ID在后台调试、日志排查、生成内部报表时，比冗长的GUID更易记录和处理，减少字符串操作的复杂度。
• 系统兼容性更强：不少旧系统或第三方工具对整数ID的支持更成熟，保留自增列能降低系统集成时的适配成本，无需全量改造为GUID兼容模式。

方案2（仅使用GUID作为主键）的潜在问题 #

• 写入性能损耗明显：GUID属于随机值，若将其设为聚集索引，每次写入都需插入到数据页的随机位置，频繁引发页分裂，磁盘IO开销会持续增加，长期运行后写入速度会显著下降。
• 查询效率偏低：执行范围查询（如按创建时间排序查询批量数据）或多表JOIN操作时，无序的GUID索引无法利用有序性进行优化，查询速度远不及整数索引——即便使用带时间戳的UUID变种，其有序性也远不如自增整数稳定。
• 索引缓存利用率低：GUID占用16字节存储空间，而自增整数最多仅8字节，相同内存容量下能缓存的整数索引条目是GUID的2倍，这会导致GUID索引的缓存命中率降低，进一步拖累查询性能。

内容的提问来源于stack exchange，提问作者tlt