假设MyTable的表结构(KEY, datafield1, datafield2…)
通常，我希望更新现有记录，或者插入不存在的新记录。
从本质上讲:
IF (key exists)
run update command
ELSE
run insert command
最好的写法是什么?
当前回答
做一个UPSERT:
UPDATE MyTable SET FieldA=@FieldA WHERE Key=@Key IF @@ROWCOUNT = 0 INSERT INTO MyTable (FieldA) VALUES (@FieldA)
http://en.wikipedia.org/wiki/Upsert
其他回答
如果执行UPDATE If -no-rows-updated then INSERT路由，考虑先执行INSERT以防止竞争条件(假设没有插入DELETE)
INSERT INTO MyTable (Key, FieldA)
SELECT @Key, @FieldA
WHERE NOT EXISTS
(
SELECT *
FROM MyTable
WHERE Key = @Key
)
IF @@ROWCOUNT = 0
BEGIN
UPDATE MyTable
SET FieldA=@FieldA
WHERE Key=@Key
IF @@ROWCOUNT = 0
... record was deleted, consider looping to re-run the INSERT, or RAISERROR ...
END
除了避免竞争条件之外，如果在大多数情况下记录已经存在，那么这将导致INSERT失败，浪费CPU。
在SQL2008以后使用MERGE可能更可取。
做一个选择，如果你得到一个结果，更新它，如果没有，创建它。
IF EXISTS (SELECT * FROM [Table] WHERE ID = rowID)
UPDATE [Table] SET propertyOne = propOne, property2 . . .
ELSE
INSERT INTO [Table] (propOne, propTwo . . .)
编辑:
唉，即使对我自己不利，我也必须承认，没有选择的解决方案似乎更好，因为它们少了一步就完成了任务。
如果您首先尝试更新，然后插入，那么竞态条件真的重要吗? 假设你有两个线程想要为key key设置一个值:
线程1:value = 1 线程2:value = 2
竞态条件场景示例
键没有定义 线程1更新失败 线程2更新失败 线程1或线程2中的一个成功插入。例如线程1 另一个线程插入失败(错误重复键)-线程2。 结果:要插入的两个步骤中的“第一个”决定值。 期望结果:最后一个线程写入数据(更新或插入)应该决定值
但;在多线程环境中，操作系统调度器决定线程执行的顺序——在上面的场景中，我们有这个竞争条件，是操作系统决定执行的顺序。从系统的观点来看，说“线程1”或“线程2”是“第一个”是错误的。
当线程1和线程2的执行时间非常接近时，竞态条件的结果并不重要。唯一的要求应该是其中一个线程应该定义结果值。
对于实现:如果更新后插入导致错误的“重复键”，这应该被视为成功。
此外，我们当然不应该假定数据库中的值与您最后写入的值相同。
许多人会建议您使用MERGE，但我提醒您不要使用它。默认情况下，它不会像多条语句那样保护你不受并发性和竞态条件的影响，它还会带来其他危险:
注意SQL Server的MERGE语句 那么，你想使用MERGE，嗯?
即使使用这种“更简单”的语法，我仍然更喜欢这种方法(为简洁起见，省略了错误处理):
BEGIN TRANSACTION;
UPDATE dbo.table WITH (UPDLOCK, SERIALIZABLE)
SET ... WHERE PK = @PK;
IF @@ROWCOUNT = 0
BEGIN
INSERT dbo.table(PK, ...) SELECT @PK, ...;
END
COMMIT TRANSACTION;
请停止使用此UPSERT反模式
很多人会这样建议:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;
IF EXISTS (SELECT 1 FROM dbo.table WHERE PK = @PK)
BEGIN
UPDATE ...
END
ELSE
BEGIN
INSERT ...
END
COMMIT TRANSACTION;
但是这样做的目的是确保您可能需要读取表两次来定位要更新的行。在第一个示例中，您只需要定位一次行。(在这两种情况下，如果从初始读取中没有找到行，则会发生插入。)
其他人会这样建议:
BEGIN TRY
INSERT ...
END TRY
BEGIN CATCH
IF ERROR_NUMBER() = 2627
UPDATE ...
END CATCH
但是，如果不考虑其他原因，让SQL Server捕获您本来可以在第一个位置防止的异常代价要高得多，那么这就有问题了，除非在几乎所有插入都失败的罕见情况下。我在这里证明:
在进入TRY/CATCH之前检查潜在的约束违反 不同错误处理技术对性能的影响
