MySQL 5.7子查询变量问题咨询：列消失、行号生成异常等

嘿，我来帮你拆解这几个MySQL变量使用的问题，都是日常写SQL时容易踩的坑，咱们一个个说清楚：

问题1：为什么(SELECT (@rowNum :=0)) AS b对应的列不显示？ #

你这里的(SELECT (@rowNum :=0)) AS b是一个派生表（临时表），它里面确实有一个结果列，但问题出在你的内层查询逻辑里：

SELECT (@rowNum:=@rowNum+1) AS rowNo,t.* FROM table_target t,(SELECT (@rowNum :=0)) AS b ...

你只选中了@rowNum递增后的rowNo，以及原表t的所有列，根本没把派生表b里的列包含到内层查询的结果集中。内层查询的输出结果集里没有b相关的列，外层自然就查不到，当你外层select b时，MySQL当然会报“未知列”的错误。

如果想要在结果里看到这个列（虽然它的值就是初始化的0，没什么实际意义），你需要在内层查询里显式选中它，比如：

SELECT (@rowNum:=@rowNum+1) AS rowNo,t.*,b.* FROM table_target t,(SELECT (@rowNum :=0)) AS b ...

问题2：(@rowNum:=@rowNum+1)是否等价于Oracle中的row_number() over ()？ #

不完全等价，但在特定场景下效果相似，咱们分情况理解：

1. 效果重叠的场景：
   当你的MySQL查询里有明确的ORDER BY（比如你例子里的ORDER BY kills DESC），并且变量初始化只执行一次时，@rowNum的递增逻辑和row_number() over (ORDER BY kills DESC)的效果是一致的——都会按照指定排序规则生成连续的行号。

2. 核心差异：

   • row_number()是标准SQL的窗口函数，它会根据OVER()子句里的PARTITION BY（分区）和ORDER BY（排序），独立计算每个分区内的行号，逻辑清晰且符合SQL规范。
   • 而MySQL的变量方式是会话级全局状态依赖：变量@rowNum是会话内的全局变量，一旦初始化后，除非手动重置，否则会一直累加；而且它没有窗口函数的分区能力——如果想要实现类似PARTITION BY的效果，需要额外加逻辑判断变量是否需要重置，写起来繁琐且容易出错。
   • 另外，MySQL 5.7本身不支持窗口函数（8.0及以后才引入），所以这种变量方式是当时实现行号的常用技巧，但它的行为不被MySQL官方完全保证，因为SQL标准里并没有规定变量赋值的执行顺序。

简单说：你例子里的写法，和row_number() over (ORDER BY kills DESC)的效果是一样的，但这只是特定场景下的巧合，不是完全等价的语法。

问题3：把(SELECT (@rowNum :=0) ) AS b放在SELECT里，行号不再递增，为什么？ #

这是因为SELECT子句中表达式的执行顺序是不确定的，而且这个子查询会被每行执行一次：

当你把(SELECT (@rowNum :=0)) AS b放到SELECT里时，MySQL在处理每行数据时，都会先执行这个子查询，把@rowNum重置为0，然后再执行@rowNum:=@rowNum+1，结果自然是1，所以所有行的行号都是1，不会递增。

而原来的写法是把变量初始化放在FROM子句里：(SELECT (@rowNum :=0)) AS b作为一个派生表，FROM子句的逻辑会在整个查询开始前执行仅一次，把@rowNum初始化为0，之后在SELECT里每行执行@rowNum:=@rowNum+1时，变量是持续累加的，所以行号会正常递增。

划重点：MySQL变量初始化一定要放到FROM子句里，确保只执行一次，这样递增逻辑才会生效。

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