MySQL 5.7 中用用户变量模拟 ROW_NUMBER() 的基本写法是：先在 FROM 子句中初始化变量（如 (SELECT @row_number := 0) AS t），再在 SELECT 中更新并引用（@row_number := @row_number + 1），且必须配合明确的 ORDER BY。
MySQL 5.7 中用用户变量模拟 ROW_NUMBER() 的基本写法
MySQL 5.7 不支持窗口函数，ROW_NUMBER() 必须靠用户变量手动实现。核心思路是：按目标排序顺序遍历数据，每行递增一个计数器变量。
典型写法是先声明并初始化变量，再在 SELECT 中更新和引用：
SELECT
@row_number := @row_number + 1 AS row_num,
id, name, score
FROM students,
(SELECT @row_number := 0) AS t
ORDER BY score DESC;
注意两点：变量初始化必须放在 FROM 子句中（否则可能因执行顺序导致结果不稳定），且 ORDER BY 必须明确——没有它，行序无定义，@row_number 递增就失去意义。
为什么不能在 WHERE 或 GROUP BY 中依赖该变量
用户变量在 MySQL 5.7 中的求值时机不保证，尤其在 WHERE、HAVING、GROUP BY 等阶段引用时，行为不可靠。官方文档明确指出：「变量赋值与表达式求值顺序未定义」。
常见错误现象：WHERE @row_number 本意取前 10 行，但实际可能过滤掉全部或部分结果，甚至报错 <code>Unknown column '@row_number' in 'where clause'。
正确做法是把变量逻辑封装在子查询或派生表里，外层再过滤：
ROW_NUMBER() OVER (PARTITION BY ...)
-
@prev_class := class_id必须放在SELECT列表末尾，确保每次取值前已更新上一行的值 -
ORDER BY必须包含分区字段（class_id）和排序字段（score），否则分组边界错乱 - 结果中最后一列
@prev_class := class_id是副作用赋值，仅用于维持状态，业务上可忽略或用NULL替代
性能和稳定性风险必须提前知道
用户变量模拟 ROW_NUMBER() 在 5.7 中本质是“伪窗口”，有硬伤：
— 查询被优化器重写（如合并子查询、下推条件）时，变量执行顺序可能改变，导致编号错位；
— 在 UNION、子查询嵌套较深、或启用 query_cache 的场景下，行为更难预测；
— 并发执行同一语句时，若变量未隔离（如用会话级变量但没重置），可能污染结果。
所以，如果数据量大（>10 万行）或要求强一致性，建议升级到 MySQL 8.0+ 直接用原生 ROW_NUMBER()；若必须守在 5.7，务必在应用层加校验逻辑，比如对编号做 HAVING COUNT(*) = MAX(row_num) 类似的兜底检查。
最易被忽略的一点：变量初始化语句 (SELECT @x := 0) 必须和主表在同一作用域，不能写成两个独立语句再拼接——因为 MySQL 5.7 不保证多语句间变量延续性。
