mysql 5.7 不支持 row_number()，执行必报 error 1064；必须用三层子查询+用户变量模拟，核心是内层强制排序物化、变量初始化置于 from 子句，并严格处理 null 比较以确保序号准确。
MySQL 5.7 执行 ROW_NUMBER() 必报 ERROR 1064
这不是配置问题、权限问题，也不是你少写了括号或拼错了单词——ROW_NUMBER() 在 MySQL 5.7 的 SQL 解析器里根本不存在。你查文档、重装、换账号，结果都一样：ERROR 1064: You have an error in your SQL syntax。官方明确：窗口函数从 MySQL 8.0.2 才开始支持，5.7 及更早版本不识别 OVER 关键字，连语法校验这关都过不去。
变量模拟必须用三层子查询 + 显式排序物化
想靠 @rank := @rank + 1 模拟出稳定序号，光写变量不够，关键在执行顺序控制。MySQL 5.7 优化器可能把 ORDER BY 下推到临时表之后，导致变量递增和逻辑排序脱钩——序号就乱了。
- 最内层子查询必须带
ORDER BY，且字段要覆盖所有分组和排序逻辑（如ORDER BY user_id, created_at DESC, id） - 变量初始化必须写在
FROM子句里，用CROSS JOIN (SELECT @rank := 0, @prev := NULL) r，不能用SET单独执行（会受连接池会话复用影响） -
IF(@prev = user_id, @rank := @rank + 1, @rank := 1)中的比较必须处理NULL：用IS NULL或COALESCE，否则首行可能得NULL而不是1 - 中间层必须加别名（如
AS ranked），否则外层WHERE rn = 1会失效
为什么不能用存储过程“实现”窗口函数
存储过程只是逻辑容器，不改变 MySQL 5.7 引擎能力上限。真正起作用的仍是用户变量 + 子查询组合，而存储过程里用游标、SELECT INTO 或 SET 初始化，反而破坏变量赋值的连续性：
- 游标每次
FETCH是独立语句，@rownum := @rownum + 1失去上下文 -
SELECT INTO只能取单行，无法支撑整结果集编号 - 临时表中转再编号，锁表久、性能差，且仍依赖外部变量逻辑
真要用存储过程，只建议做调用封装，把可靠子查询包一层，别在里面重写变量逻辑。
ORDER BY 缺唯一键会导致序号不可复现
哪怕你绕过版本限制、写对了变量逻辑，如果排序字段有重复值（比如只按 created_at 降序），MySQL 5.7 会在相同时间戳的行之间随机排先后，每次查出来的 @rank 值可能不同——这不是 bug，是未定义行为。
- 验证方法：
SELECT created_at, COUNT(*) FROM orders GROUP BY created_at HAVING COUNT(*) > 1 - 补救方式：在
ORDER BY后追加唯一字段，如created_at DESC, id DESC或created_at DESC, order_no - 避免用
RAND()或业务上不稳定的字段兜底，否则调试和线上复现都困难
真正麻烦的从来不是“怎么写”，而是“怎么让每一次执行都返回同样结果”。变量模拟本身脆弱，再加上排序依据不稳，上线后查半天才发现是时间精度丢了。
