mysql 5.7中用@rownum加行号本质是用户变量自增模拟，非原生窗口函数；必须同一select内初始化并递增变量、显式order by保证顺序，且禁用where/having中引用该变量。
MySQL 5.7里用@rownum给查询结果加行号，本质是变量自增，不是窗口函数
MySQL 5.7不支持ROW_NUMBER()这类标准窗口函数，得靠用户变量模拟。核心逻辑是：初始化一个变量，每扫一行就+1，并在SELECT中引用它。但要注意——变量赋值顺序依赖ORDER BY执行时机，而MySQL优化器可能重排执行顺序，导致行号错乱。
- 必须把变量初始化和查询写在同一语句里（用
JOIN (SELECT @rownum := 0) r或SET @rownum := 0再查），不能分开执行后复用 -
ORDER BY必须显式写在最终SELECT里，且不能被子查询“吞掉”；如果套了多层子查询，行号可能按内层顺序生成，而非外层想要的排序 - 避免在
WHERE或HAVING里引用行号变量——此时变量尚未按目标顺序递增，值不可控
正确写法：先ORDER BY再变量自增，用:=而非=
常见错误是写成@rownum = @rownum + 1，这在MySQL里是条件判断（返回0或1），不是赋值。必须用:=。同时，变量递增和排序必须绑定在同一扫描过程。
SELECT @rownum := @rownum + 1 AS row_num, id, name, score FROM students CROSS JOIN (SELECT @rownum := 0) r ORDER BY score DESC, id;
-
CROSS JOIN (SELECT @rownum := 0)确保每次查询都重置变量，避免会话残留值干扰 -
ORDER BY放在最外层，保证排序完成后再逐行赋值 - 如果要跳过前N条（比如分页），不能直接
LIMIT，得套一层子查询：SELECT * FROM (上面整个查询) t WHERE row_num > 10
为什么SELECT @rownum := @rownum + 1有时返回NULL或重复数字
根本原因是MySQL对用户变量的求值时机未定义（non-deterministic）。尤其当查询涉及GROUP BY、DISTINCT或某些JOIN时，优化器可能把变量计算提前或延后。例如：
- 在
GROUP BY语句里用@rownum，变量可能在分组聚合前就递增，导致每组只计1次，而非每行1次 - 使用
UNION时，变量不会跨SELECT延续，第二个分支的@rownum还是初始值 - 如果表有大量数据且启用了并行读（如某些存储引擎配置），变量甚至可能被多个线程同时修改，结果完全不可预测
替代方案：能不用变量就别用，优先考虑应用层或升级
用户变量实现行号是临时 workaround，稳定性差，不适合生产环境关键逻辑。更稳妥的做法：
- 把排序和编号逻辑移到应用代码里（PHP/Python/Java等），查出有序结果后用循环加索引，可控且易调试
- 如果必须数据库侧处理，且能控制MySQL版本，升级到8.0+直接用
ROW_NUMBER() OVER (ORDER BY ...)，语义清晰、性能更好、无副作用 - 实在卡在5.7又需要稳定行号，可用自连接统计比当前行“更大”的记录数（如
(SELECT COUNT(*) FROM students s2 WHERE s2.score > s1.score)），但O(n²)复杂度，数据量大时极慢
变量行号看似简单，实际踩坑点全在执行计划不可控上——同一个SQL，在不同数据量、不同索引、不同MySQL patch版本下，结果都可能不同。
