不同Windows Service操作同一张SQL Server表的INSERT与UPDATE性能问题

首先你目前考虑的两个方案都无法解决核心的锁竞争问题：存储过程仅能降低语句解析开销，对锁冲突导致的延迟没有明显改善；主动等待逻辑反而会降低整体吞吐量，属于下策。
按落地成本从低到高、收益从高到低推荐优化方案：

1. 锁与隔离级别优化（零代码改动，收益最高） #

• 开启SQL Server 读提交快照隔离级别（RCSI），开启后读操作不会加共享锁，写操作的排他锁也不会阻塞读操作，能直接消除大部分读写冲突开销，配置方式为在数据库属性中开启「读取提交快照」选项即可。
• 执行查询时添加锁提示减少冲突：service2的UPDATE语句修改为UPDATE table1 WITH (READPAST) SET ... WHERE id IN (...)，READPAST会直接跳过已经被其他事务锁定的行，不会产生锁等待。

2. 表与索引优化 #

• 确保id字段是table1的聚集主键，这样UPDATE通过id定位行的速度最快，锁粒度会保持在行级，不会升级为页锁/表锁，大幅降低锁冲突范围。
• 清理table1上多余的非聚集索引，INSERT操作需要同步维护所有索引，多余索引会直接降低批量插入的速度，仅保留业务必需的索引即可。

3. 业务逻辑优化 #

• 针对队列场景优先做读写拆分：新增一张单独的结果表，service2处理完数据后直接INSERT到结果表，不要UPDATE原表，原表仅保留INSERT操作，完全消除读写锁冲突，性能至少提升2倍以上。
• 若必须保留原表UPDATE逻辑，service2取待处理数据时统一使用WITH (UPDLOCK, READPAST)提示，提前拿取更新锁，避免死锁，同时跳过已被锁定的行无需等待。

4. 批量操作优化 #

• 批量INSERT操作改用C#的SqlBulkCopy类实现，比拼接VALUES语句的插入效率高30%以上，尤其后续批次量提升时优势更明显。
• 若单次UPDATE的id数量超过100个，建议将id列表写入临时表后关联UPDATE，比IN子句的执行效率更高，锁持有时间更短。

5. 架构层解耦（长期最优） #

如果后续服务数量还会增加，引入进程内/分布式消息队列解耦两个服务的依赖：service1产生数据后写入消息队列，service2从队列消费数据处理后再写入数据库，两个服务完全不需要争抢同一张表的锁，天然不存在同步问题。

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