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

  • 时间:
  • 浏览:2
  • 来源:大发5分快乐8_极速5分11选5

考虑只是你什儿 场景,或许还挺常见的:大伙要能 在关系数据库中更新一行或多行数据的多个字段,更新完了还不算,还得拿到被更新的某一两个字段的结果。

有都越来越你什儿 妙招,既太久再开启事务,又要能准确拿到 update 的结果呢?去 StackOverflow 看看吧~

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

只是,为了你什儿 小需求,都越来越随意就开一两个事务,Code Review 的过有的是被架构师驳回的吧?只是你什儿 完整篇 走索引的查询,服务器和数据库之间网络通信的时间开销只是数据库内查询的时间开销的好多倍,再来个 begin 和 commit 这两活宝,果然只是生生把查询耗时翻倍的节奏。只是就只是在多表更新你什儿 要能 保证原子性的地方不得已开个事务,你什儿 小需求也开事务话语,总很重杀鸡用牛刀的感觉。

为什么会把别的请求挡掉呢?加事务呗,只是事务隔离级别要能 在 Read committed 及以上。事务一现在刚始于就用 update 给那一行用行锁给锁定了,别的请求能否否 等到 select 返回事务现在刚始于要能去 update 同一行。

基本上 select from update 适用于什么要能 从更新的记录中读取你什儿 字段的场景,很重是要能根据索引定位到少数的有多少记录的之后,性能表现良好。

第两个例子,点赞。

真的都越来越妙招用一两个查询玩转信用卡 吗?

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

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

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

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

肯能你觉得你什儿 增强要能帮助改善系统性能,不妨试试~反正我用过之后,就现在刚始于嫌弃不支持你什儿 功能的 Oracle MySQL 了!

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

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

第一两个参数传批量获取的数量 N,第两个参数传主键标识,只是子从读取到的最大可用主键现在刚始于,往前推 N 个有的是可用的不重复的主键。

存储过程?肯能把 begin,update,select,commit 两个话语写到一两个存储过程上面,网络通信次数就从四次减少到一次了,性能提升 75%!想归想做归做,之后总听架构师说,大伙的系统是互联网架构,肯能都越来越很重的理由,业务逻辑都得放在应用服务器中,数据库只做存储不做业务。你什儿 小需求应该拿都越来越什么很重的理由去用存储过程吧。

且不论你什儿 生成器怎么才能 才能 实现,考虑到主键是 insert 操作必不可少的字段,主键生成器要能 高性能高可用,你什儿 策略只是批量获取主键并缓处在内存中,只是子能否成百上千倍地减少对主键生成器的请求。

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

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

诶,网络通信的确是个麻烦的事情,有都越来越妙招把你什儿 事务上面的网络通信开销减少你什儿 呢?肯能事务上面耗时减少,占用连接的时间就相应减少,系统就要能承载更多的并发请求!

呵呵,用户体验你什儿 尚方宝剑真好用呢~

注意到这两条 SQL 话语都越来越一两个事务中,只是 select 话语拿到的 count 太久一定是它前面那条 update 更新的结果,肯能被别的 update 更新了,什么都 用户不仅仅感受到了从点下鼠标现在刚始于,到数据库现在刚始于执行 update 这段时间内你什儿 用户的热情,还感受到了从 update 执行后,到 select 现在刚始于执行这段时间内你什儿 用户的热情。

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

肯能你正在使用阿里云 RDS,能否尝试只是你什儿 写法,把 update 和 select 合并为一根 SQL,进一步减少网络开销和数据库开销,提升性能。

还真发现有人问了类事的大现象,7 年之后。觉得都越来越用一两个查询玩转信用卡 ,只是还是有妙招在不开事务的条件下实现的!借助一两个变量,把更新的结果放在变量里,只是再在同一两个 session 中把变量值读出来。的确是你什儿 巧妙的做法。

哎哟不错哦,你什儿 妙招好。

发现你什儿 大现象之后,后端工程师就现在刚始于想啊,只是那个用户体验至上的产品经理觉得你什儿 感受热情的时间窗口太长了,用户体验不好,想把上面那段从 update 到 select 的时间窗口拿掉,为什么会么会办?你什儿 时间窗口只是有别的请求过来,数据肯定就污染了,得把别的请求挡在外面,没 select 完之后都别 update。

在你什儿 大现象被提出来的之后,在 MySQL 上面,还果然都越来越妙招用一两个查询玩转信用卡 。甚至直到现在,在 Oracle 维护的官方版本的 MySQL 里头,还是都越来越用一两个查询玩转信用卡 。

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

肯能 Web 应用在和数据库交互的之后有的是使用连接池,执行 SQL 前获取一两个连接,只是在连接里巴拉巴拉执行一堆 SQL,只是再把连接还给连接池,什么都 大伙基本上太久再担心 update 和 select 都越来越一两个 session 的情况报告,一般来说假如代码保证 update 和 select 在同一两个连接上执行就好了。

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

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

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

只是你什儿 世界上,MySQL 有的是什么都 分支啊,除了彻底分裂出去的 MariaDB,还有 Percona 你什儿 号称完整篇 兼容 MySQL 的增强版。除了提供源码的 Percona,还有 Alibaba 维护的 AliSQL,还有数据库即服务的 阿里云 RDS。