MySQL 5.7 无法在存储过程中真正实现窗口函数，因其执行引擎不支持行级有序累积计算；可靠模拟仅靠用户变量（@rownum、@group）配合子查询内排序与 CROSS JOIN 初始化，任何游标、SET 或动态 SQL 均会破坏编号连续性。
MySQL 5.7 原生不支持窗口函数，存储过程本身也不能“实现”窗口函数——它只是封装逻辑的容器，不能绕过 SQL 引擎的能力限制。真正能模拟 ROW_NUMBER()、RANK() 等行为的，是用户变量（@rownum、@group）配合严格排序的 SELECT 查询。存储过程最多起包装作用，且容易引入新问题。
为什么不能在存储过程中“实现”窗口函数？
窗口函数本质是 SQL 执行引擎在结果集上按行、分组、有序地做累积计算。MySQL 5.7 的执行器不提供该能力，用户变量的赋值顺序又依赖查询计划，而存储过程里的 SELECT ... INTO 或游标遍历会破坏变量递增的连续性，导致编号错乱或全为 1。
- 游标逐行 FETCH 时，每次 fetch 是独立语句，
@rownum := @rownum + 1不再是单次查询内的确定性求值 -
SELECT ... INTO只能取单行，无法承载“对整个结果集编号”的语义 - 存储过程中用临时表中转再编号，性能差、锁表久，且仍要依赖外部变量逻辑
真正可用的模拟方式：变量 + 子查询（非存储过程）
所有稳定可行的 ROW_NUMBER() 模拟都基于一条 SELECT，核心是：排序必须在子查询内完成，变量初始化必须用 CROSS JOIN 绑定到该查询生命周期。
- 全局编号（等价于
ROW_NUMBER() OVER (ORDER BY score DESC)）：SELECT @rownum := @rownum + 1 AS row_num, t.name, t.score FROM (SELECT name, score FROM students ORDER BY score DESC) t CROSS JOIN (SELECT @rownum := 0) r;
- 分组编号（等价于
ROW_NUMBER() OVER (PARTITION BY class ORDER BY score DESC)）：SELECT @rownum := CASE WHEN @group = class THEN @rownum + 1 ELSE 1 END AS row_num, @group := class, name, class, score FROM (SELECT name, class, score FROM students ORDER BY class, score DESC) t CROSS JOIN (SELECT @rownum := 0, @group := '') r;
- 必须确保
ORDER BY在子查询里；写在外层 SELECT 中，MySQL 5.7 不保证变量更新顺序
如果硬要用存储过程，只推荐做“调用封装”，别做“逻辑实现”
把上述可靠 SELECT 封装成存储过程，仅用于统一接口或权限控制，不改变底层机制。注意以下三点：
- 过程内不要 SET 初始化变量（如
SET @rownum = 0），改用CROSS JOIN子查询，否则跨调用可能残留旧值 - 避免在过程里拼接动态 SQL 并 PREPARE/EXECUTE —— 用户变量在 prepare 阶段不可见，必报错或返回 NULL
- 若需返回结果集，直接
SELECT ...即可；不要试图用游标循环构造结果，那只会让排名失效
变量模拟的脆弱性在于 MySQL 5.7 对用户变量求值时机未定义，哪怕加了 ORDER BY，优化器也可能重排执行顺序。最稳妥的长期解法仍是升级到 MySQL 8.0+；若暂时不能升，就死守“子查询内排序 + CROSS JOIN 初始化”这一条铁律，其他任何包装（包括存储过程）都是徒增复杂度。
