MySQL 5.7 不支持窗口函数，只能用用户变量在单条 SELECT 中严格模拟：排序须在子查询内完成，变量初始化需 CROSS JOIN 绑定，赋值与使用必须同轮扫描；分组编号需双变量且更新顺序正确，否则结果不可靠。
ROW_NUMBER()、FIRST_VALUE() 这类窗口函数在 MySQL 5.7 中根本不存在，不是配置没开、也不是权限问题，是内核不识别语法，执行直接报 ERROR 1064 (42000)。想“实现”，只能绕过 SQL 引擎限制，用用户变量 + 严格可控的查询结构来模拟行为。
为什么不能在存储过程中“实现”窗口函数
存储过程只是逻辑容器，它不改变 MySQL 5.7 查询引擎的能力边界。真正出问题的是执行顺序不可控：
- 游标
FETCH是逐行独立语句，@rownum := @rownum + 1每次都从初始值重算，编号全变成 1 -
SELECT ... INTO只能取单行，无法承载“对整个结果集编号”的语义 - 用临时表中转再编号，要额外加锁、写磁盘，性能差，且仍依赖外部变量逻辑，没解决根本问题
- 任何
SET @var = 0放在过程开头，都可能被客户端缓存或跨语句失效
可靠模拟必须满足的三个硬条件
所有稳定可用的 ROW_NUMBER() 模拟，都基于一条 SELECT，缺一不可：
- 排序必须在子查询（派生表）内完成：
ORDER BY写在外层 SELECT 中，MySQL 5.7 不保证变量更新顺序 - 变量初始化必须用
CROSS JOIN绑定到该查询生命周期，例如(SELECT @rownum := 0) r - 变量赋值和使用必须在同一 SELECT 的同一轮扫描中完成，不能拆成多条语句
典型正确写法：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
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;
分组编号（PARTITION BY）容易踩的坑
模拟 ROW_NUMBER() OVER (PARTITION BY class ORDER BY score DESC) 时，关键不是“怎么写”，而是“怎么不写错”：
- 必须用两个变量：
@group记上一行分组键，@rownum记当前序号 - 判断逻辑和赋值必须在同一行、且顺序不能颠倒：
@rownum := IF(@group = class, @rownum + 1, 1)必须在@group := class之前，否则判断用的是旧值 -
ORDER BY必须包含分组字段和排序字段，缺一不可；只写ORDER BY class会导致同组内行顺序不确定，编号跳跃 - 初始化要同时设置：
(SELECT @group := '', @rownum := 0) r，不能分开SET
错误示例（编号全乱）：
-- ❌ 错误：ORDER BY 缺少 score，且变量更新顺序反了 SELECT @rownum := IF(@group = class, @rownum + 1, 1), @group := class, name, score FROM students ORDER BY class;
替代方案选型：变量 vs 子查询 vs 应用层
没有银弹，只有权衡：
- 用户变量方案快，但极度脆弱——只要加个
GROUP BY、套个视图、或者优化器选择物化子查询，就失效 - 自连接/相关子查询（如
WHERE (SELECT COUNT...) ）语义清晰、兼容性好，但 N² 复杂度，数据量过万就明显变慢 - 应用层排序（如 Java/Python 拿到全量后处理）最可控，适合小结果集或需复杂业务逻辑的场景，但网络传输和内存占用会上升
真正难的不是写出第一版能跑的 SQL，而是当表加了索引、数据量翻倍、或 DBA 调整了 optimizer_switch 后，它还是否稳定返回预期结果——这点变量方案几乎无法保障。
