MySQL中CASE语句里:=条件为假仍执行的原因及解决方法

为什么@rn:=@rn+1在条件为假时仍会执行 #

MySQL处理SELECT子句中的表达式时，会先对所有表达式求值，再根据CASE的条件判断返回对应分支结果。也就是说，不管WHEN的条件是否成立，@rn:=@rn+1这个赋值操作都会被执行——用户变量的赋值是即时生效的，只要该表达式出现在SELECT列表中，MySQL就会执行它，而非仅在条件满足时才执行。这就导致即使当前行应该保持@rn不变，变量也已经被递增，最终出现不符合预期的分组编号。

解决方法 #

方法1：修正用户变量的使用逻辑 #

把变量赋值操作完全限制在条件满足的分支里，else分支直接返回当前的@rn，确保变量仅在需要时递增。可以用IF函数替代CASE：

SET @rn = 0;

WITH tasks AS (
    SELECT DISTINCT Start_Date, End_Date
    FROM Projects
    ORDER BY Start_Date
)
SELECT
    Start_Date,
    End_Date,
    @rn := IF(LAG(End_Date, 1) OVER(ORDER BY Start_Date) != Start_Date, @rn + 1, @rn) AS cnt
FROM tasks;

这里只有当条件成立时，才会执行@rn + 1并赋值给@rn，否则直接返回当前@rn，避免了不必要的变量递增。

方法2：使用窗口函数（更推荐，无需用户变量） #

现代SQL可通过窗口函数生成分组标识，无需依赖用户变量。核心思路是：计算每个Start_Date减去其行号（按Start_Date排序）的日期差，连续日期会得到相同差值，以此作为分组依据：

WITH tasks AS (
    SELECT DISTINCT Start_Date, End_Date
    FROM Projects
    ORDER BY Start_Date
),
ranked_tasks AS (
    SELECT
        Start_Date,
        End_Date,
        DATE_SUB(Start_Date, INTERVAL ROW_NUMBER() OVER(ORDER BY Start_Date) DAY) AS group_id
    FROM tasks
)
SELECT
    MIN(Start_Date) AS Start_Date,
    MAX(End_Date) AS End_Date
FROM ranked_tasks
GROUP BY group_id
ORDER BY Start_Date;

这种方法避免了用户变量的副作用，逻辑更清晰，也符合SQL标准，兼容性更好。

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