记一次批量更新整型类型的列 → 探究 UPDATE 的使用细节 _生活百科

开心一刻今天，她给我打来电话
她：你明天陪我去趟医院吧
我：怎么了
她：我怀孕了，陪我去打胎
我：他的吗
她：嗯
我心一沉，犹豫了片刻：生下来吧，我养！
她：他的孩子，你不配养！
我：我随孩子姓

文章插图
需求背景最近接到一个数据迁移的需求，旧系统的数据迁移到新系统；旧系统不会再新增业务数据，业务操作都在新系统上进行
为了降低迁移的影响，数据进行分批迁移，也就是说新旧系统会并行一段时间
数据分批不是根据 id 范围来分的，也就说每批数据的 id 都是无规律的
另外，为了保证新旧系统数据的对应，新系统的 id 尽可能的沿用旧系统的 id
因为表 id 在新旧系统都是自增的，所以迁移的时候，旧系统的 id 可能在新系统已经被占用了，类似如下

文章插图
需求描述数据迁移的时候，尽可能沿用旧系统的 id，而冲突的 id 需要进行批量调整
如何调整这批冲突的 id，正是我当下要实现的需求
我的实现是根据业务数据的增长情况，结合目前新系统的最大 id 来预设一个起始的 id

文章插图
这个 SQL 该如何写？
需求实现有小伙伴可能觉得，这还不简单？
不就 5 条数据嘛，这么写不就搞定了

文章插图
多简单的事，还铺垫那么多，楼主你到底会不会？
楼主此刻幡然醒悟：小伙伴，你好厉害哇哦

文章插图
但是如果冲突的数据很多了（几百上千），你也这样一条一条改？
如果你真这样做，我是真心佩服你

文章插图
很显然，理智的小伙伴更多
那该如何实现了？
楼主就不卖关子了，可以用局部变量 + UPDATE 来实现，直接上 SQL

文章插图
我们来看实际案例
表 tbl_batch_update

文章插图
数据如下

文章插图
执行效果如下

文章插图
更新之后

文章插图
更严谨点

文章插图
该如何实现？ UPDATE 是不是也支持 ORDER BY ？
还真支持，如下所示

文章插图
楼主平时使用 UPDATE 的时候，基本没结合 ORDER BY ，也没尝试过结合 LIMIT
这次尝试让楼主对 UPDATE 产生了陌生的感觉，它的完整语法应该是怎样的？我们慢慢往下看
UPDATE下文都是基于 MySQL 8.0 的官方文档 UPDATE Statement 整理而来，推荐大家直接去看官方文档
单表语法

文章插图
是不是有很多疑问：

文章插图
多表语法

文章插图
相比于单表，貌似更简单一些，不支持 ORDER BY 和 LIMIT
LOW_PRIORITY UPDATE 的修饰符之一，用来降低 SQL 的优先级
当使用 LOW_PRIORITY 之后， UPDATE 的执行将会被延迟，直到没有其他客户端从表中读取数据为止
但是，只有表级锁的存储引擎才支持 LOW_PRIORITY ，表级锁的存储引擎包括： MyISAM 、 MEMORY 和 MERGE ，所以最常用的 InnoDB 是不支持的