最可靠方式是用update+order by配合用户变量实现递减赋值，需在子查询中初始化变量并显式order by desc；mysql 8.0+推荐用row_number()窗口函数替代。
直接用 UPDATE + ORDER BY 实现递减赋值最可靠
MySQL 不支持在 INSERT 或 UPDATE 中直接生成“从 N 到 1”的连续递减序列（比如给 5 行数据的 rank 字段分别设为 5、4、3、2、1），但可以用用户变量配合 ORDER BY 在单条 UPDATE 里完成。这是目前最稳定、无需触发器或存储过程的方式。
- 必须用
ORDER BY ... DESC控制更新顺序，否则变量递增逻辑会错乱 - 变量初始化必须在子查询中完成，不能只写
SET @var := 0后跟UPDATE—— MySQL 8.0+ 严格模式下可能被忽略 - 不能依赖
id自增顺序来隐式排序；显式写ORDER BY id DESC才能保证最大id拿到最小序号（如 1）
示例：给 tb_student 表按 id 降序分配 age 值 5→1
UPDATE tb_student JOIN (SELECT @rn := 0) AS _init SET age = (@rn := @rn + 1) ORDER BY id DESC;
触发器无法自动实现“全局递减序列”
触发器适合响应单行插入/更新，但无法感知“当前表总行数”或“已有最大序号”，所以不能安全地维护一个“每次新增就自动填入当前总行数”的递减字段。常见误用是：
- 在
INSERT触发器里查SELECT COUNT(*)再赋值 —— 并发插入时会重复计数，导致序号冲突 - 用
MAX(rank)获取上一个值再减 1 —— 同样存在竞态，且无法处理批量插入 - 试图在触发器里修改新插入行以外的其他行 —— MySQL 禁止“对同一张表进行 SELECT 和 UPDATE/INSERT 交叉操作”
结论：BEFORE INSERT 或 AFTER INSERT 触发器不适合生成递减序列，强行用会引入数据不一致风险。
存储过程能做但没必要，且易出错
如果坚持用存储过程，核心逻辑仍是模拟上面的变量更新，但多了一层封装和事务控制。问题在于：
- 调用前需手动传入起始值、步长、目标列名等参数，灵活性反而不如一条
UPDATE - 若过程内没加
START TRANSACTION，遇到部分失败时无法回滚，容易留下中间状态 - 调试困难：变量作用域、执行顺序、错误中断点都不如原生 SQL 直观
真正需要存储过程的场景，是配合业务规则做条件递减（例如“每个部门内按薪资倒序排 rank”），此时得嵌套 GROUP BY + 窗口函数（MySQL 8.0+）或变量分组模拟，而不是单纯全局递减。
MySQL 8.0+ 推荐用 ROW_NUMBER() 替代变量
如果你用的是 MySQL 8.0 或更高版本，ROW_NUMBER() OVER (ORDER BY ... DESC) 是更清晰、更符合 SQL 标准的替代方案，尤其适合生成临时序号：
- 无需担心变量初始化时机或执行顺序
- 可直接用于
SELECT结果，也可结合UPDATE ... JOIN赋值（需用派生表包裹） - 天然支持分区递减（如
PARTITION BY dept_id ORDER BY salary DESC）
安全赋值示例（避免直接 UPDATE 窗口函数）：
UPDATE tb_student t
JOIN (
SELECT id, ROW_NUMBER() OVER (ORDER BY id DESC) AS rn
FROM tb_student
) r ON t.id = r.id
SET t.rank = r.rn;
注意：窗口函数不能直接出现在 SET 右侧，必须先查出结果再关联更新。
真正麻烦的不是语法，而是想清楚“递减”到底依附于什么逻辑 —— 是全表顺序？某个字段排序？还是业务分组？变量和窗口函数都只是工具，选哪个取决于你是否需要并发安全、是否允许重复执行、以及 MySQL 版本约束。
