MySQL 5.7及更早版本可用用户变量模拟行号，但必须在单SELECT中完成初始化与递增、显式ORDER BY保证顺序，且不可用于GROUP BY或嵌套查询中；模拟PARTITION BY需双变量配合判断重置。
MySQL 5.7 及更早版本怎么给结果集加行号
没有 ROW_NUMBER() 就没法排序后编号？不是。用用户变量可以模拟，但必须严格控制执行顺序，否则编号会错乱甚至复位。关键点在于：变量赋值和使用必须在同一个 SELECT 的同一轮扫描中完成，且不能被优化器拆开。
常见错误是把变量初始化和主查询分开写成两条语句，比如先 SET @row := 0 再 SELECT @row := @row + 1 —— 在某些客户端或连接模式下，这两条语句可能跨事务或被缓存，导致编号从 0 开始失败。
- 必须在单个
SELECT中完成初始化和递增：@row := IFNULL(@row, 0) + 1或前置(SELECT @row := 0) AS _ - 必须用
ORDER BY显式排序，且该ORDER BY要作用于整个变量计算过程；仅在外层ORDER BY无效 - 不能在
GROUP BY或聚合函数后直接用变量编号，因为分组会改变行处理顺序
如何保证 ROW\_NUMBER 按分组重置（即 PARTITION BY 效果）
模拟 PARTITION BY dept_id ORDER BY salary DESC，本质是检测“当前行的分区键是否和上一行不同”。需要两个变量：@dept 记录上一行的部门，@row 记录当前序号。一旦 @dept 变化，就重置 @row。
注意：变量比较必须在 ORDER BY 已确保相邻行属于同一逻辑分组的前提下才可靠。如果 ORDER BY 缺失或字段不完整（比如只写 ORDER BY dept_id 却没写 salary），相同 dept_id 的行可能被任意打乱，导致编号跳跃。
- 初始化要同时设置两个变量：
(SELECT @dept := '', @row := 0) AS _ - 判断逻辑写在
SELECT列中：@row := IF(@dept = dept_id, @row + 1, 1) - 紧接着更新
@dept：@dept := dept_id—— 这步必须放在行内，且顺序不能颠倒，否则判断用的是旧值
为什么在 JOIN 或子查询里用变量容易出错
嵌套查询中变量行为不可靠，尤其当 MySQL 优化器选择物化子查询（materialization）或使用临时表时，变量不会按预期逐行执行。典型表现是：外层 SELECT 看到的始终是变量的最终值（比如全是 100），而不是每行一个递增数。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
例如写成 SELECT * FROM (SELECT @row := @row + 1 AS rn, name FROM t) AS tmp，看似合理，但 MySQL 可能先执行内层并缓存结果，再对外层赋值，导致 @row 只被计算一次或顺序错乱。
- 避免在派生表（derived table）中依赖变量编号；改用外层一次性扫描
- 如果必须嵌套，把变量逻辑提到最外层
SELECT，内层只做数据准备 - JOIN 多表时，务必确认驱动表顺序 —— 变量只随驱动表的行流递增，被驱动表的重复匹配会导致编号重复
MySQL 8.0+ 用户别硬套变量方案
如果你实际用的是 MySQL 8.0 或更高版本，直接用原生 ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)。变量方案不仅难维护，还无法利用窗口函数的执行计划优化，性能差一到两个数量级，且不支持帧子句（ROWS BETWEEN）等高级特性。
真正需要变量方案的场景只剩两个：一是被迫维护老旧系统（MySQL 5.6/5.7），二是极特殊逻辑（比如编号依赖上一行某个计算字段，而该字段本身又由变量生成）。其他情况都应优先升级或改用 CTE + 窗口函数。
