MySQL 8.0+ 应使用 ROW_NUMBER() 窗口函数实现行号生成，语义清晰、执行确定；5.7-需用临时表+变量三步法；分组编号必须依赖窗口函数，变量方案不可靠。
MySQL 8.0+ 直接用 ROW_NUMBER() 窗口函数最稳
只要你的 MySQL 版本 ≥ 8.0，就别绕弯子——ROW_NUMBER() 是唯一推荐的方案。它语义清晰、执行确定、不依赖会话变量，且能天然支持分组（PARTITION BY）和排序组合。
在存储过程中，必须用 CTE（WITH 子句）包裹窗口函数结果，再通过 UPDATE ... JOIN 写回原表；不能在 UPDATE 里直接嵌套 ROW_NUMBER()，否则会报语法错误。
-
DELIMITER //必须加，否则存储过程体内的分号会让 MySQL 提前终止解析 - CTE 中的
ORDER BY决定序号顺序，升序/降序要写明确，比如ORDER BY created_at DESC - 如果原表没主键或唯一键，
JOIN关联时可能匹配多行，导致更新错乱——务必确保关联字段是唯一标识（如id）
MySQL 5.7 或更低版本只能靠用户变量 + 临时表
变量方案看着短，但在存储过程中直接用 @var := @var + 1 在 SELECT 里递增，极大概率失效：优化器可能重排执行顺序，或在多行并发更新时序号跳变、重复、错位。
真正可靠的做法是拆成三步：初始化变量 → 插入排序后带序号的临时表 → 关联更新。临时表不是可选项，是必须项。
- 必须用
CREATE TEMPORARY TABLE，不是普通表，避免并发调用冲突 -
INSERT INTO ... SELECT ... ORDER BY这一句里，ORDER BY要紧挨着SELECT，不能丢到外面，否则序号生成顺序无保证 - 变量赋值必须写在
SELECT列表中，例如@row_num := @row_num + 1 AS rn，不能只写在SET里再查 - 最后记得
DROP TEMPORARY TABLE IF EXISTS，虽然会话结束自动清理，但显式释放更稳妥
UPDATE 语句里混用变量和 ORDER BY 是高危操作
很多人试图这样写：UPDATE t SET row_num = @rn := @rn + 1 ORDER BY time_，看起来简洁，但 MySQL 官方文档明确说明：UPDATE 中的 ORDER BY 不保证执行顺序，尤其在有索引、有 WHERE 条件、或启用并行查询时，变量递增完全不可控。
这种写法在小数据量、单线程、无索引的测试环境可能“碰巧”对，一旦上生产，序号错乱就是常态。
- 哪怕你加了
WHERE条件限定范围，也不能挽救执行顺序不确定性 - MySQL 5.7 对这类写法会发警告（
Unsafe statement written to the binary log），8.0+ 可能直接报错 - 替代方案只有两个：走 CTE（8.0+）或走临时表（全版本兼容）
分组内编号（PARTITION BY）必须用窗口函数
如果你的需求是“每个用户按登录时间排序，每人从 1 开始编号”，即分组内独立计数，那用户变量方案几乎无法安全实现。手动模拟 PARTITION BY user_id ORDER BY login_time 需要同时维护多个状态变量（当前分组、上一分组、序号计数），极易出错，且无法处理空值或边界 case。
而 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_time) 一行解决，逻辑封闭、结果确定。
- 分组字段类型要一致，比如
user_id是VARCHAR却和INT比较，会导致分区失效 - 如果分组字段允许 NULL，所有 NULL 值会被归为同一组，这是标准行为，不是 bug
- 不要试图用
GROUP BY替代PARTITION BY，前者聚合行，后者保留原行——目标完全不同
真正麻烦的从来不是“怎么写出来”，而是“怎么确保每次运行都对”。窗口函数省心，变量方案费神——选哪个，取决于你愿不愿意为确定性多写几行代码、多建一张临时表。
