为何ORDER BY会影响SELECT中变量计算？SQL执行顺序疑问

核心原因：数据处理顺序的变化 #

在MySQL中，用用户变量（比如@r1）在SELECT子句中赋值时，变量的计算完全依赖数据被处理的顺序：

• 无ORDER BY时：数据库会按照数据在表中的存储顺序（或引擎默认读取顺序，比如InnoDB的主键顺序）逐行处理，变量按这个原始顺序累加。
• 添加ORDER BY Name后：MySQL会先把所有符合条件的数据提取出来，按Name排序生成临时结果集，再对这个排序后的结果集逐行执行SELECT子句的变量赋值。变量的累加顺序变成了排序后的顺序，自然RowNumber的计算结果会改变。

直观示例 #

假设OCCUPATIONS表的原始存储顺序是：

无ORDER BY的处理流程

按原始顺序Eve → Alice → Bob处理：

• 处理Eve：@r1从0变为1，RowNumber为1，Doctor列显示Eve
• 处理Alice：@r1从1变为2，RowNumber为2，Doctor列显示Alice
• 处理Bob：@r2从0变为1，RowNumber为1，Professor列显示Bob

加ORDER BY Name后的处理流程

按排序后顺序Alice → Bob → Eve处理：

• 处理Alice：@r1从0变为1，RowNumber为1，Doctor列显示Alice
• 处理Bob：@r2从0变为1，RowNumber为1，Professor列显示Bob
• 处理Eve：@r1从1变为2，RowNumber为2，Doctor列显示Eve

两种场景下RowNumber的对应关系完全不同，这就是问题的根源。

额外提示：用户变量的风险 #

MySQL官方文档明确说明：在同一个SELECT语句中同时进行变量赋值和读取，行为是未定义的——数据库不保证表达式的执行顺序，不同版本或场景下可能出现不一致结果。

针对Hackerrank的Occupations题目，更可靠的标准SQL写法是使用窗口函数：

SELECT
  ROW_NUMBER() OVER (PARTITION BY Occupation ORDER BY Name) AS RowNumber,
  CASE WHEN Occupation='Doctor' THEN Name END AS Doctor,
  CASE WHEN Occupation='Professor' THEN Name END AS Professor,
  CASE WHEN Occupation='Singer' THEN Name END AS Singer,
  CASE WHEN Occupation='Actor' THEN Name END AS Actor
FROM OCCUPATIONS
ORDER BY Name;

这种写法逻辑清晰，每个职业内部的行号会稳定按Name排序生成，不受外部ORDER BY的干扰。

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