嗨，针对你提到的SQL Server主键设计问题，我结合实际项目经验给你拆解下几种方案的优劣，帮你做更适合的决策：

先梳理你的核心方案选项 #

• 方案1：Sale和SaleItem各自用基于原复合键生成的Uniqueidentifier作为单主键，同时保留原业务字段（company、code等）
• 方案2：Sale用Uniqueidentifier主键，SaleItem用SaleId + Item的复合主键
• 方案3：完全沿用原系统的复合键作为主键（Sale用company+code+year，SaleItem用company+code+year+item）

各方案的优缺点分析 #

方案1：基于原键生成的Uniqueidentifier单主键 #

优势

• 外键关联更简洁：后续其他表引用Sale或SaleItem时，只需要存一个Uniqueidentifier字段，比存多字段复合键更省存储空间，代码里传递参数、写关联逻辑也更省心。
• 原业务字段独立存储：不用从Uniqueidentifier里解析业务信息，直接用company、year这些字段做业务查询更直观，避免了解析逻辑的额外开销。

劣势

• 写入性能隐患：Uniqueidentifier是无序值，如果把它设为聚集索引（SQL Server默认主键就是聚集索引），每次插入数据都会导致数据页分裂，批量导入时这个问题会被放大，严重影响写入效率。
• 额外维护成本：你需要自己严格维护Uniqueidentifier的生成规则，确保和原复合键一一对应，一旦规则出错就会导致数据混乱，增加了开发和测试的工作量。

方案2：Sale用Uniqueidentifier主键，SaleItem用SaleId+Item复合主键 #

优势

• 平衡简洁性与性能：既保留了Sale表外键关联的简洁性，SaleItem的复合主键相对纯UUID来说，写入时的页分裂概率更低（同一Sale下的Item通常是连续的，插入时会集中在相近的数据页）。
• 减少逻辑复杂度：不用额外维护SaleItem的Uniqueidentifier生成逻辑，降低了出错风险。

劣势

• 外键引用略繁琐：后续关联SaleItem的表需要同时存储SaleId和Item两个字段，写关联条件时要同时匹配两个字段，代码量会比单主键多一点。
• 若SaleId是完全无序的UUID，还是会有一定的页分裂问题，但比方案1的纯UUID主键要好很多。

方案3：完全沿用原系统的复合键作为主键 #

优势

• 贴合业务逻辑：完全复用原系统的业务键，不需要额外生成主键，避免了UUID相关的所有问题。
• 写入与查询性能更优：如果复合键是天然有序的（比如按year+company+code排序），作为聚集索引时，批量导入数据会有序插入，几乎不会产生页分裂；同时复合键的总字节数（比如company(1)+code(8)+year(2)=11字节）比Uniqueidentifier（16字节）小，非聚集索引的叶子节点占用空间更少，查询效率更高。

劣势

• 外键引用太繁琐：后续所有关联Sale的表都要存company、code、year三个字段，关联SaleItem的表要存四个字段，代码里写关联条件容易漏写字段，维护成本很高。
• 复合键索引键长度更长，若后续建大量非聚集索引，会占用更多存储空间。

综合建议 #

1. 如果你的系统批量导入需求大、写入频率高，且后续关联表不多，优先考虑方案3，或者可以折中：把原复合键设为聚集索引，同时给Sale和SaleItem加一个非聚集的Uniqueidentifier主键（不过这样会增加索引维护的额外开销）。
2. 如果后续关联表多，代码简洁性优先，且写入量不是特别大，推荐方案2——它在简洁性和性能之间做了很好的平衡，比方案1的纯UUID主键更靠谱。
3. 尽量避免方案1的纯UUID主键，除非你能接受写入性能的损失，或者可以调整聚集索引到原复合键上，但这样主键和聚集索引分离，会增加系统复杂度。

另外补充个小技巧：如果一定要用Uniqueidentifier，尽量让生成的UUID带有顺序性（比如把year、company这类有序的业务字段放在UUID的前几个字节），这样能大幅减少插入时的页分裂，提升写入性能。

备注：内容来源于stack exchange，提问作者rcs