编写仅含自增主键表的Upsert存储过程，用NULL参数是否符合惯例？

方案合理性判断 #

这种允许主键参数传入NULL的做法，确实是这类场景下的惯用解决方案。因为你的表仅将自增主键作为唯一标识，插入操作时调用方无法预知主键值，只能通过NULL来区分「插入新行」和「更新已有行」两种场景。

关于MERGE子句的说明 #

你写的MERGE匹配逻辑是可行的，但可以调整写法让逻辑更清晰：

-- 优化后的MERGE匹配条件
ON [Target].[PrimaryKey] = [Source].[PrimaryKey]

结合MERGE的WHEN NOT MATCHED THEN INSERT分支来看：当@PrimaryKeyParam为NULL时，Source的主键值也为NULL，此时匹配条件永远不成立，自然触发插入逻辑；当传入有效的主键值时，就会匹配目标表对应行执行更新。

如果你对NULL参数的写法感到不安，也可以改用更直观的分支逻辑，完全绕开MERGE的NULL匹配：

IF @PrimaryKeyParam IS NOT NULL
BEGIN
    -- 执行更新操作
    UPDATE [Target]
    SET [列1] = @列1参数, [列2] = @列2参数
    WHERE [PrimaryKey] = @PrimaryKeyParam
END
ELSE
BEGIN
    -- 执行插入操作，自增主键由数据库自动生成
    INSERT INTO [Target] ([列1], [列2])
    VALUES (@列1参数, @列2参数)
    -- 如需返回生成的主键，可添加以下语句
    SELECT SCOPE_IDENTITY() AS NewPrimaryKey
END

这种分支写法逻辑直白，更贴近常规的SQL编写习惯，能消除你对NULL匹配的顾虑。

补充建议 #

• 若后续表中新增业务唯一键，建议优先用业务唯一键作为Upsert的匹配条件，这样调用方无需依赖主键，更贴合业务逻辑。
• 无论采用MERGE还是分支写法，都要注意并发场景下的锁冲突问题，必要时可添加事务控制。

内容的提问来源于stack exchange，提问作者J. Mini