更新多行数据,然后把更新的结果读出来,这样的 SQL 要怎么写?

  • 时间:
  • 浏览:3

且不论累似 生成器咋样实现,考虑到主键是 insert 操作必不可少的字段,主键生成器前要高性能高可用,累似 策略要是批量获取主键并缓所处内存中,那我子可不前要成百上千倍地减少对主键生成器的请求。

在累似 疑问图片被提出来的后来,在 MySQL 上边,还你以为没能 辦法 用一个多多查询玩转信用卡 。甚至直到现在,在 Oracle 维护的官方版本的 MySQL 里头,还是没能 用一个多多查询玩转信用卡 。

还真发现其他同学问了累似 的疑问图片,7 年后来。嘴笨 没能 用一个多多查询玩转信用卡 ,后来还是有辦法 在不开事务的条件下实现的!借助一个多多变量,把更新的结果贴到 变量里,后来再在同一个多多 session 中把变量值读出来。的确是累似 巧妙的做法。

诶,网络通信的确是个麻烦的事情,有没能 辦法 把累似 事务上边的网络通信开销减少或多或少呢?可能性事务上边耗时减少,占用连接的时间就相应减少,系统就才能承载更多的并发请求!

呵呵,用户体验累似 尚方宝剑真好用呢~

存储过程?可能性把 begin,update,select,commit 一个多励志的话 写到一个多多存储过程上边,网络通信次数就从四次减少到一次了,性能提升 75%!想归想做归做,后来总听架构师说,大伙的系统是互联网架构,可能性没能 不为什么我么我的理由,业务逻辑都得贴到 应用服务器中,数据库只做存储不做业务。累似 小需求应该拿这么哪此不为什么我么我的理由去用存储过程吧。

发现累似 疑问图片后来,后端工程师就开始想啊,要是那个用户体验至上的产品经理嘴笨 累似 感受热情的时间窗口太长了,用户体验不好,想把上边那段从 update 到 select 的时间窗口拿掉,怎摸办?累似 时间窗口要是有别的请求过来,数据肯定就污染了,得把别的请求挡在外面,没 select 完后来都别 update。

前要注意的是,累似 增强语法并没能 在云数据库文档中明确给出,将其应用于生产环境前,最好先咨询相关专家。

后来累似 世界上,MySQL 总要 或多或少分支啊,除了彻底分裂出去的 MariaDB,还有 Percona 累似 号称完整版兼容 MySQL 的增强版。除了提供源码的 Percona,还有 Alibaba 维护的 AliSQL,还有数据库即服务的 阿里云 RDS。

可能性 Web 应用在和数据库交互的后来总要使用连接池,执行 SQL 前获取一个多多连接,后来在连接里巴拉巴拉执行一堆 SQL,后来再把连接还给连接池,或多或少大伙基本上时会担心 update 和 select 这么一个多多 session 的状态,一般来说只要代码保证 update 和 select 在同一个多多连接上执行就好了。

再考虑那我累似 场景:大伙前要在关系数据库中更新一行或多行数据的多个字段,更新完了还不算,还得拿到这批被更新的记录的主键,以便操作或多或少的有关联的表。

没能 说我知道你太抽象,就拿点赞计数来打个比方(做为点赞狂魔的我,前不久才在大伙的 博文 下面强行点了 666 个赞)。

于是呢,后端工程师回去写出了那我的 SQL:

做为后端工程师当然想实现为前者,多简单啊,一个多多 update 励志的话 更新一下 gmt_modified 和 count 后来返回 OK 就玩转信用卡 了,要不然还得多查一下。后来前端工程师不乐意了,可能性能让后端接口多返回点数据给前端多好,没能 没头没脑的 +1 就把业务逻辑掺进来了,说好的后端负责数据前端负责展现呢。

做为例子,这里尝试列举多少适合使用 select from update 累似 增强语法的场景。

可能性你正在使用阿里云 RDS,可不前要尝试那我累似 写法,把 update 和 select 合并为四根 SQL,进一步减少网络开销和数据库开销,提升性能。

第一个多多例子,电子商务系统中的库存扣减,和点赞正好是反向操作,点赞是加,库存是减。

那我,为了累似 小需求,没能 随意就开一个多多事务,Code Review 的后来会被架构师驳回的吧?那我累似 完整版走索引的查询,服务器和数据库之间网络通信的时间开销要是数据库内查询的时间开销的好多倍,再来个 begin 和 commit 这两活宝,你以为要是生生把查询耗时翻倍的节奏。那我就要是在多表更新累似 前要保证原子性的地方不得已开个事务,累似 小需求也开事务励志的话 ,总不为什么我么我杀鸡用牛刀的感觉。

假设有那我一张表,就叫 likes 好了,记录了一个多多网站上边每个能被点赞的对象被赞的次数。id 是一个多多无业务含义的自增主键,gmt_xxx 分别是无业务含义的记录创建时间和记录更新时间。object_id 是能被点赞的对象的主键,大慨外键的作用,只不过由应用逻辑去保证关联表的数据一致性,数据库不感知;count 字段记录的是累似 对象被赞的次数。

哎哟不错哦,累似 辦法 好。

于是大伙在页面上点了赞,前端页面向后端服务 POST 一个多多请求, 后端服务要记录这次点赞行为。于是前端和后端工程师在点赞 API 的返回值上开始讨论:是后端简单返回一个多多 OK 表示成功除理,前端收到 OK 后在页面上自行把点赞数 +1 呢,还是后端除了返回 OK 表示成功,前要返回当时累似 对象的被赞次数,后来前端在页面上更新被赞次数?

注意到这两条 SQL 励志的话 这么一个多多事务中,后来 select 励志的话 拿到的 count 太久一定是它前面那条 update 更新的结果,可能性被别的 update 更新了,或多或少用户不仅仅感受到了从点下鼠标开始,到数据库开始执行 update 这段时间内或多或少用户的热情,还感受到了从 update 执行后,到 select 开始执行这段时间内或多或少用户的热情。

真的没能 辦法 用一个多多查询玩转信用卡 吗?

第一个多多参数传批量获取的数量 N,第一个多参数传主键标识,那我子从读取到的最大可用主键开始,往前推 N 个总要 可用的不重复的主键。

基本上 select from update 适用于哪此前要从更新的记录中读取或多或少字段的场景,不为什么我么我是才能根据索引定位到少数的多少记录的后来,性能表现良好。

考虑那我累似 场景,或许还挺常见的:大伙前要在关系数据库中更新一行或多行数据的多个字段,更新完了还不算,还得拿到被更新的某一个多多字段的结果。

第一个多例子,点赞。

为什么我么我把别的请求挡掉呢?加事务呗,后来事务隔离级别前要在 Read committed 及以上。事务一开始就用 update 给那一行用行锁给锁定了,别的请求能才能了等到 select 返回事务开始才能去 update 同一行。

前后端撕逼大战引起了产品经理的注意。产品经理说,返回当时的被赞次数能让用户感受到或多或少用户的热情,就没能 定了,为了用户体验!

第一个多多例子,分布式唯一主键生成器。

关于累似 增强的用法,其原理、性能对比等等,详见其作者的博文 Oracle/PostgreSQL UPDATE…RETURNING…在MySQL中的实现,本文不赘述。

可能性你嘴笨 累似 增强才能帮助改善系统性能,不妨试试~反正我用过后来,就开始嫌弃不支持累似 功能的 Oracle MySQL 了!

有没能 或多或少辦法 ,既时会开启事务,又才能准确拿到 update 的结果呢?去 StackOverflow 看看吧~

在面临较大的访问流量时,大伙一般会将数据库水平拆分,成为数据库集群,数据根据分表字段散列到不同的数据库主从节点上。在单库单表的数据库中,大伙的表的主键通常用的是一个多多自增的数字,后来水平拆分后来就能才能了没能 用了,为了保证不同分表的数据依然满足主键唯一的约束,大伙前要一个多多分布式的主键生成器。

于是那我子就能写出基本满足功能的点赞 API 了!