已有Salesforce分配ID的表新增IDENTITY(INT)主键是否符合技术最佳实践？

是否要替换主键需要结合你的数据规模、业务场景判断，绝大多数场景下优先保留Salesforce ID作为主键，不需要改成自增IDENTITY列，具体原因如下：

性能对比 #

• 存储开销差距极小：varchar(18)的Salesforce ID单条存储占用18字节，相比4字节的int自增主键、8字节的bigint自增主键，单条最多多占14字节，哪怕是千万级的表，总存储差距也只有百MB级别，对现代数据库来说完全可以忽略。
• 插入性能差异仅在高写入场景感知明显：Salesforce ID是全局无序的，如果作为SQL Server默认的聚集索引主键，批量插入时会出现索引页分裂的问题，写入性能比顺序递增的自增主键低10%~30%，但如果你的单表数据量在百万级以下、ETL是每日/小时级的批量同步，这点性能差异几乎感知不到。
• 关联查询性能差距不大：只要是索引覆盖的关联查询，不管用varchar类型的Salesforce ID还是数值型自增ID，执行效率的差异在常规业务查询中可以忽略。

维护成本对比 #

• 保留Salesforce ID作为主键的成本极低：ETL逻辑可以直接做UPSERT匹配，无需额外维护ID映射关系；排查数据问题、对接Salesforce周边系统时，直接用原生ID即可匹配，不需要做ID转换，出bug的概率极低。
• 换成自增主键会大幅提升复杂度：你需要额外在ETL流程中维护Salesforce ID和自增ID的映射关系，关联写入（比如EmailMessage关联Case）时需要先查询关联表的自增ID再写入，不仅ETL逻辑变复杂，排查问题时还要来回核对两套ID的映射关系，维护成本高很多。

适用场景建议 #

• 绝大多数场景（数据镜像、报表分析、常规业务查询）：直接保留Salesforce ID作为主键即可，不需要做调整。
• 如果你遇到明确的写入性能瓶颈、单表数据量超过5000万：可以不用修改主键，仅调整索引结构：将自增IDENTITY列设为聚集索引，Salesforce ID保留为非聚集主键，既解决了无序写入的页分裂问题，又不用修改ETL的关联逻辑，是性价比最高的折中方案。
• 仅当你有其他业务系统必须用数值型主键关联这套数据时，才值得将主键替换为自增IDENTITY列，同时给Salesforce ID建立唯一非聚集索引用于同步和关联。

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