UPDATE语句匹配多值时如何选择赋值？SQL实例疑问

你的担心完全合理——第一段代码的UPDATE逻辑绝对不可靠，必须改成第二段那种用MIN()显式聚合的写法，具体原因和分析如下：

为什么第一段代码“碰巧”能得到正确结果？ #

你观察到的1月24日选中最小符合值，只是SQL Server执行计划的巧合。当UPDATE语句中一个目标行（#Dates里的某条记录）匹配到多个源行（BDate里的多条记录）时，SQL Server没有定义应该选择哪一行的值来更新目标列。它可能随机选取任意一行的值——这次碰巧选了最小的CDate，但下次执行时（比如数据量变化、索引重建、执行计划优化器选择不同路径），很可能会返回其他值，结果完全不可预测。

你第一段代码中的关键风险点就是这段未定义行为的UPDATE：

UPDATE d 
SET d.BDate = b.CDate 
FROM #Dates d 
JOIN BDate b ON d.CDate <= b.CDate

这段逻辑里，每个d.CDate会匹配所有大于等于它的b.CDate，但SQL Server不会自动帮你筛选出最小的那个，当前的正确结果只是偶然现象。

第二段代码的正确性与必要性 #

你的第二种写法通过BDMin子查询，用MIN(b.CDate)明确为每个d.CDate计算出最小的符合条件的业务日期，再通过关联更新到#Dates表：

, BDMin AS ( 
    SELECT d.CDate , MIN(b.CDate) AS BDate 
    FROM #Dates d 
    JOIN BDate b ON d.CDate <= b.CDate 
    GROUP BY d.CDate 
)

这种写法的逻辑完全明确：

1. 先通过聚合函数MIN()和GROUP BY，确保每个CDate只对应一个确定的BDate（即最小的符合条件的日期）
2. 再通过一对一的关联关系执行更新，彻底消除了多匹配行带来的不确定性

这是处理“为每行找到最小/最大匹配值”这类场景的标准、稳妥做法，能保证结果始终符合你的预期，不受执行计划或数据变化的影响。

总结 #

绝对有必要使用第二种写法！第一段代码的“正常工作”只是偶然的未定义行为，在生产环境中会导致数据错误，完全不能依赖。

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