MySQL 5.7 不支持窗口函数，需用用户变量模拟，但必须将 ORDER BY 锁定在子查询中、变量初始化与查询耦合、按从左到右顺序使用变量，否则结果不可靠。
MySQL 5.7 不支持窗口函数，但可以用用户变量（@var）模拟 ROW_NUMBER()、RANK()、DENSE_RANK() 等行为。关键不是“能不能写出来”，而是“写出来的结果是否稳定可靠”——很多看似能跑通的 SQL，在数据量变大、加了 GROUP BY、或被优化器重排后就出错。
为什么直接用 @rn:=@rn+1 + ORDER BY 不行
常见错误写法：SET @rn=0; SELECT *, @rn:=@rn+1 AS rn FROM emp ORDER BY dept_id, salary DESC;
问题在于：MySQL 5.7 的执行顺序不保证变量赋值发生在排序之后。即使你写了 ORDER BY，优化器仍可能先计算变量再排序，导致序号乱序。尤其在开启 sql_mode=STRICT_TRANS_TABLES 或使用派生表时更明显。
- 变量初始化必须和查询耦合在同一个语句中，不能靠
SET分开执行 -
ORDER BY必须出现在最内层子查询里，不能只放在外层 - 避免在
WHERE子句中同时做变量赋值（如WHERE @rn:=@rn+1），这会触发未定义行为
正确模拟 ROW_NUMBER() OVER(PARTITION BY dept_id ORDER BY salary DESC)
核心是：把排序锁死在子查询中，并在外部查询中安全递增变量。示例：
SELECT id, name, dept_id, salary, @rn := IF(@prev_dept = dept_id, @rn + 1, 1) AS row_num, @prev_dept := dept_id FROM ( SELECT id, name, dept_id, salary FROM emp ORDER BY dept_id, salary DESC, id ) AS sorted, (SELECT @rn := 0, @prev_dept := '') AS init;
注意点：
-
ORDER BY必须在子查询中，且排序字段要足够唯一（补上id防止相同salary导致顺序不可控） -
IF()中的比较必须严格类型一致：@prev_dept初始化为''，而dept_id是数字？那就得初始化为0，否则隐式转换会让第一行永远不匹配 - 最后一列
@prev_dept := dept_id是为了下一行判断，它本身没有业务意义，但不能省——否则变量不会更新
RANK() 和 DENSE_RANK() 的变量逻辑差异
三者区别只在“并列如何处理”：
-
ROW_NUMBER()：纯递增，无并列（@rn := @rn + 1） -
RANK()：并列时跳号，需记录上一行的salary值：@prev_sal；当前行salary = @prev_sal→ 复用上一个 rank，否则@rank := @rank + 1 -
DENSE_RANK()：并列不跳号，逻辑同RANK()，但递增时用@dense_rank := IF(@prev_sal = salary, @dense_rank, @dense_rank + 1)
所有变量都必须在同一个 SELECT 列表中按从左到右顺序出现，MySQL 5.7 保证这个顺序执行——这是唯一能依赖的确定性机制。
性能与兼容性踩坑点
变量方案本质是单线程逐行计算，无法并行，大数据量时比 MySQL 8.0 的窗口函数慢一个数量级。更隐蔽的问题是：
- 在存储过程中多次调用同一段变量 SQL，可能因变量未重置导致序号累加（必须每次带
(SELECT @x:=0)初始化） - 如果表有
UNION或复杂JOIN，变量作用域可能跨结果集失效 - MySQL 5.7.21+ 对变量警告升级为错误（
Setting user variables within expressions is deprecated），虽然还能用，但日志刷屏 - 任何涉及
GROUP BY的外层查询，都会让变量计数完全错乱——此时只能放弃纯 SQL 方案，改用应用层排序
真正稳定的替代方案，从来不是“怎么写更巧”，而是“什么时候该放弃 SQL 层模拟”。当查询需要分页 + 排名 + 过滤组合时，变量已不可靠；这时宁可查出原始数据，在 Java/Python 中用 enumerate() 或 rank(method='min') 处理，反而更可控。
