SQL Server 2008中处理Insert/Update语句的最佳方式是什么？

我之前处理过好几个类似的业务场景，针对你提到的重复逻辑冗余和死锁频发这两个核心痛点，分享几个在实际项目中验证过的解决思路：

一、用数据库原生UPSERT替代服务端判断，消除冗余代码 #

传统方式需要在服务端先查询、再分支判断执行Insert还是Update，不仅代码重复率高，还多了一次数据库往返。直接用数据库的UPSERT语法，能把这两步合并成一条语句，从根源减少冗余：

不同数据库的UPSERT示例： #

• MySQL/MariaDB：依赖INSERT ... ON DUPLICATE KEY UPDATE

  INSERT INTO your_table (id, col1, col2)
  VALUES (1, 'val1', 'val2')
  ON DUPLICATE KEY UPDATE
    col1 = VALUES(col1),
    col2 = VALUES(col2);
  

  注意：需要确保id是主键或唯一索引，数据库才能识别冲突并执行更新。

• PostgreSQL：使用INSERT ... ON CONFLICT ... DO UPDATE

  INSERT INTO your_table (id, col1, col2)
  VALUES (1, 'val1', 'val2')
  ON CONFLICT (id) DO UPDATE SET
    col1 = EXCLUDED.col1,
    col2 = EXCLUDED.col2;
  

• SQL Server：借助MERGE语句实现

  MERGE INTO your_table AS target
  USING (SELECT 1 AS id, 'val1' AS col1, 'val2' AS col2) AS source
  ON target.id = source.id
  WHEN MATCHED THEN
    UPDATE SET col1 = source.col1, col2 = source.col2
  WHEN NOT MATCHED THEN
    INSERT (id, col1, col2) VALUES (source.id, source.col1, source.col2);
  

这种方式把Insert/Update的判断逻辑交给数据库处理，服务端只需要执行这一条语句，再也不用写两套重复的SQL和判断代码了。

二、优化事务与锁机制，解决死锁问题 #

死锁通常是因为事务持有锁的顺序不一致、事务范围过大导致的，针对这些问题可以从以下几点入手：

• 缩小事务范围：不要把无关操作塞进同一个事务。比如更新数据时，只包含必要的查询和UPSERT语句，避免事务长时间持有锁。
• 统一资源访问顺序：如果多个事务需要操作多个表或行，确保所有事务都按照相同的顺序访问这些资源。比如先更新表A再更新表B，所有事务都遵守这个顺序，就能避免循环等待导致的死锁。
• 调整事务隔离级别：如果业务允许，降低隔离级别（比如从REPEATABLE READ降到READ COMMITTED），减少数据库加锁的范围和时长。
• 避免长事务：不要在事务中加入IO操作（比如调用外部API、读写文件），这类操作会让事务长时间处于活跃状态，大幅增加死锁概率。
• 添加死锁重试机制：即使做了优化，死锁还是可能偶发。可以在服务端捕获死锁异常，自动重试3-5次，大部分情况下重试就能成功。

额外建议：封装通用UPSERT工具类 #

如果你的系统用了ORM框架（比如MyBatis、Hibernate），可以封装一个通用的UPSERT方法，让业务代码不用关心不同数据库的语法差异，进一步减少冗余。比如在MyBatis里写通用Mapper，或者在Spring Boot里封装Service层的通用处理方法。

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