- 综合排序
- 最热优先
- 最新优先
- 来自专栏idba
浅谈一致性读
一 前言 MySQL 在不同的事务隔离级别下提供两种读模式 一致性读(非加锁), 当前读(加锁读)。本文主要研究一致性读取。 在RR模式下,同一个事务内的一致性读的快照都是基于第一次读取操作时所建立的。下面我们做测试进行对RR模式下一致性读进行解读。 a. RR模式下的一致性读，是以第一条select语句的执行时间点作为snapshot建立的时间点的，即使是访问不同的表。 image.png c. 四 当前读 和一致性读不太一样 ，当前读需要使用select xx for update，或者 lock in share mode ,读取最新的数据并且锁定被访问的行，(RC 加行锁，RR加gap 参考文章 [1] 一致性读深入研究 [2] 官方文档
50330发布于 2018-08-09 - 来自专栏飞天小牛肉
三分钟小短文：一致性非锁定读与一致性锁定读
台上三分钟，台下三小时，兄弟们，今天咱们花三分钟了解下数据库中的两种读（select）操作：一致性非锁定读 和 一致性锁定读 一致性非锁定读 一致性非锁定读是什么？ 也就是说，在事务 1 刚开始的时候，id = 1 的数据行是什么样，现在读到的就是什么样的： 可以结合下面这张图来回顾下上述的过程： 一致性锁定读 其实从名字上也能看出来，非一致性锁定读适用于对数据一致性要求不是很高的情况 也即，非锁定读机制极大地提高了数据库的并发性。 而一致性锁定读适用于对数据一致性要求比较高的情况，这个时候我们需要对读操作进行加锁以保证数据逻辑的一致性。 其它事务可以向被锁定的行加 S 锁，但是不允许添加 X 锁，否则会被阻塞住 So，如何用大白话解释一致性锁定读？上面这两条特殊的 select 语句就是一致性锁定读！ 一致性锁定读就是给行记录加 X 锁或 S 锁！ 简单不？
63920编辑于 2022-02-23 - 来自专栏爱可生开源社区
技术分享 | 什么是半一致性读？
---- 什么是半一致性读？ 先看下官方的描述： 是一种用在 Update 语句中的读操作（一致性读）的优化，是在 RC 事务隔离级别下与一致性读的结合。 测试案例 InnoDB 引擎的强大之处就在于它能完美地支持事务，而事务的一致性则是由事务隔离级别和并发事务锁来保证的。接下来，我们先通过 2 个测试案例来观察半一致性读会对事务产生哪些影响。 Session 3：同样地，最开始也需要对读取到的记录一条条加锁，由于 id=7 的记录与 id=4、id=5 上的行锁并不冲突，此处可以利用半一致性读对 Update 的优化特性，提前将 id=7 上的行锁释放掉了 Session 2：由于 Session 1 已经将全部记录都上了 X 锁，Session 2 当前读的 Select 操作由于无法获取任何记录的 X 锁，就被阻塞了。 总结 在 RC 事务隔离级别下，Update 语句可以利用到半一致性读的特性，会多进行一次判断，当 where 条件匹配到的记录与当前持有锁的事务中的记录不冲突时，就会提前释放 InnoDB 锁，虽然这样做违背了二阶段加锁协议
4.1K30发布于 2020-06-28 - 来自专栏程序员历小冰
MySQL探秘(六):InnoDB一致性非锁定读
一致性非锁定读(consistent nonlocking read)是指InnoDB存储引擎通过多版本控制(MVVC)读取当前数据库中行数据的方式。 上图直观地展现了InnoDB一致性非锁定读的机制。之所以称其为非锁定读，是因为不需要等待行上排他锁的释放。快照数据是指该行的之前版本的数据，每行记录可能有多个版本，一般称这种技术为行多版本技术。 一致性非锁定读是InnoDB默认的读取方式，即读取不会占用和等待行上的锁。但是并不是在每个事务隔离级别下都是采用此种方式。此外，即使都是使用一致性非锁定读，但是对于快照数据的定义也各不相同。 在事务隔离级别READ COMMITTED和REPEATABLE READ下，InnoDB使用一致性非锁定读。然而，对于快照数据的定义却不同。 由于InnoDB在READ COMMITTED和REPEATABLE READ事务隔离级别下使用一致性非锁定读，这时如果会话A再次读取id为1的记录，仍然能够读取到相同的数据。
1.2K20发布于 2018-11-26 - 来自专栏腾讯云数据库(TencentDB)
TDSQL全局一致性读技术详解
针对这一点，腾讯云数据库TDSQL设计了全局一致性读方案，解决了分布式节点间数据的读一致性问题。 TDSQL全局一致性读方案 刚刚介绍了为什么分布式下会存在一致性读的问题，接下来分享TDSQL一致性读的解决方案： 首先引入了全局的时间戳服务，它用来对每一笔事务进行标记，即每一笔分布式事务绑定一个全局递增的序列号 至此，我们有了全局一致性读的基本思路和方案，下一步就是针对优化项的考虑了。 一致性读下的性能优化 这部分内容的是在上述解决方案的基础上进行的优化。 即TDSQL可以提供两种一致性服务，一种是全局一致性读，即基于全局GTS串行化实现，另外一种是关闭这个开关，只保证事务最终一致性。 开启一致性读特性虽然能够解决分布式场景下的可重复读问题，但是由于新引入了全局GTS组件，该组件一定程度上属于关键路径组件，如果其故障业务会受到短暂影响。除此之外， 全局一致性读对性能也有一定影响。
2.1K92发布于 2021-11-05 - 来自专栏程序员历小冰
MySQL探秘(六):InnoDB一致性非锁定读
一致性非锁定读(consistent nonlocking read)是指InnoDB存储引擎通过多版本控制(MVVC)读取当前数据库中行数据的方式。 一致性非锁定读示意图 上图直观地展现了InnoDB一致性非锁定读的机制。之所以称其为非锁定读，是因为不需要等待行上排他锁的释放。 一致性非锁定读是InnoDB默认的读取方式，即读取不会占用和等待行上的锁。但是并不是在每个事务隔离级别下都是采用此种方式。此外，即使都是使用一致性非锁定读，但是对于快照数据的定义也各不相同。 在事务隔离级别READ COMMITTED和REPEATABLE READ下，InnoDB使用一致性非锁定读。然而，对于快照数据的定义却不同。 由于InnoDB在READ COMMITTED和REPEATABLE READ事务隔离级别下使用一致性非锁定读，这时如果会话A再次读取id为1的记录，仍然能够读取到相同的数据。
57010发布于 2019-01-23 - 来自专栏aoho求索
MySQL探秘(六):InnoDB一致性非锁定读
一致性非锁定读(consistent nonlocking read)是指InnoDB存储引擎通过多版本控制(MVVC)读取当前数据库中行数据的方式。 一致性非锁定读示意图 上图直观地展现了InnoDB一致性非锁定读的机制。之所以称其为非锁定读，是因为不需要等待行上排他锁的释放。 一致性非锁定读是InnoDB默认的读取方式，即读取不会占用和等待行上的锁。但是并不是在每个事务隔离级别下都是采用此种方式。此外，即使都是使用一致性非锁定读，但是对于快照数据的定义也各不相同。 在事务隔离级别READ COMMITTED和REPEATABLE READ下，InnoDB使用一致性非锁定读。然而，对于快照数据的定义却不同。 由于InnoDB在READ COMMITTED和REPEATABLE READ事务隔离级别下使用一致性非锁定读，这时如果会话A再次读取id为1的记录，仍然能够读取到相同的数据。
57940发布于 2018-12-17 - 来自专栏爱可生开源社区
技术分享 | etcd 与 Consul 的一致性读对比
etcd[1] 和 Consul[2] 是现在比较流行的分布式一致性 KV 存储，本文就来分享和对比一下这两个存储的一致性读的实现。 1Consul 一致性读的实现 Consul 有三种读模式： default consistent stale 其中 stale 是非一致性的读模式，而 default 和 consistent 是一致性的 小结 从这几段逻辑可以看出，Consul 的一致性读是通过转发读请求给 Leader 来实现的。 2etcd 一致性读的实现 etcd 的读分为串行读（Serialize）和线性读（Linearizable）两种模式。其中线性读是一致性的读模式。 同样的我们来看下一致性读的实现： 可以看到串行读和线性读的区别只是在串行读之前调用了 linearizableReadNotify 方法。
1.1K10编辑于 2023-12-11 - 来自专栏数据和云
【深度好文】有关延迟块清除和一致性读
本文进一步讨论一些有关延迟块清除和一致性读方面的内容. 先来看看一个数据块中ITL的转储： ? 如果一个SQL语句对该块进行一致性读时，发现ITL中的Upper bound的SCN比一致性读需要的SCN大，这时会发生什么？ 要回答这些问题，先来看下面的一系列测试过程： 1. 基于这个原理，会话1知道，ITL中需要清除的事务小于等于UNDO段头中TRN CTL记录的SCN，而这个SCN值已经比它的一致性读SCN要小，所以会话1足够判断不需要回滚该事务就能得到一致性读结果，所以这个时候 上面的测试这也证明了本文得到的两个结论： 在一致性读时进行块清除，并不需要得到事务的精确提交SCN（尽管它通过回滚事务表可能会得到精确的提交SCN），只需要它发现事务的提交SCN比自己的一致性读的时间点小就可以了 如果在一致性读时发现了更小的（更接近精确提交的）SCN值或精确的提交SCN值，它还会做一次块清除，修改ITL，以记录更小或更精确的SCN。 ?
1.5K50发布于 2018-03-07 - 来自专栏huofo's blog
MySQL事务（二）事务隔离的实现原理：一致性读
实际上，这个快照是基于InnoDB在实现MVCC时用到的一致性读视图来实现的。 MVCC的全称是“多版本并发控制”。 在更新时如何使用一致性读 image.png 图3 示例1 我们来看示例1，如果事务B在事务C更新之前查询，这个查询返回值是1。 而事务B是当前读，而且必须要加锁，因此被锁住了，必须等到事务C'释放这个锁，才能继续它的当前读。 到这里，把一致性读、当前读和行锁串起来了。 小结 本节问题，事务的可重复读隔离级别是如何实现的？ 可重复读的核心就是一致性读；而事务更新数据的时候，只能用当前读。如果当前的记得的行锁被其他事务占用的话，就需要进入锁等待。 读提交 读提交的实现方式跟可重复读类似，它们最主要的区别是： 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图； 在读提交隔离级别下，每个语句执行前都会重新算出一个新的视图
52540编辑于 2022-03-18 - 来自专栏数据和云
变与不变: Undo构造一致性读的例外情况
其中介绍了Oracle如何使用UNDO来实现多版本一致性读，使用了OPEN CURSOR的方式非常巧妙地在很少量数据的情况下构造出可重现的案例。 我们先来模拟一下UNDO构造一致性读的情况，对于Oracle而言，默认的隔离级别是READ COMMIT，也就是说一个会话只能看到其他会话已经提交的修改，未提交的修改或者在当前会话查询发起之后提交的修改都是不可见的 PRINT :C NAME ------------------------------------------------------------ UPDATED WITH PK 可以看到例外产生了，一致性读的结果被破坏了 Oracle11g以后，这个隐含参数默认值修改为TRUE，这使得Oracle对于基于主键的访问不再采用默认的一致性读方案。 :C NAME ------------------------------------------------------------ I_EXTERNAL_TAB1$ Oracle恢复默认的读一致性隔离级别
57420发布于 2018-12-18 - 来自专栏luozhiyun的技术学习
SOFAJRaft源码分析— 透过RheaKV看线性一致性读
开篇 其实这篇文章我本来想在讲完选举的时候就开始讲线性一致性读的，但是感觉直接讲没头没尾的看起来比比较困难，所以就有了RheaKV的系列，这是RheaKV，终于可以讲一下SOFAJRaft的线性一致性读是怎么做到了的 线性一致性读readIndex 所谓线性一致读，一个简单的例子是在 t1 的时刻我们写入了一个值，那么在 t1 之后，我们一定能读到这个值，不可能读到 t1 之前的旧值(想想 Java 中的 volatile ) 方法向 Leader 发送 ReadIndex 请求，交由Leader节点实现一致性读。 所以我这里主要介绍Leader的一致性读。 总结 我们这篇文章从RheaKVStore的客户端get方法一直讲到，RheaKVStore服务端使用JRaft实现线性一致性读，并讲解了线性一致性读是怎么实现的，通过这个例子大家应该对线性一致性读有了一个相对不错的理解了
83610发布于 2019-11-18 - 来自专栏腾讯云数据库(TencentDB)
数据库大牛李海翔详解全局读一致性技术
本次分享，基于数据库事务处理的核心技术并发访问控制技术和分布式系统CAP理论中的一致性，TDSQL原创性提出了全面地解决读一致性的算法，是的，分布式事务的一致性和分布式系统的一致性统一在一起。 --读半已提交数据异常 业界是怎么解决读半已提交数据异常问题的？ 分布式事务型数据库，解决了读半已提交数据异常，就一劳永逸了吗？ TDSQL的事务处理模型 什么是全局一致性？ 典型的例子如仿Spanner的CockroachDB，通过SSI实现了可串行化解决了事务类型的数据异常，但是不能解决全局读一致性的问题（需要全局排序才能解决全局读一致性问题，但混合时钟机制做不到全局有序 一是分布式读一致性，二是分布式事务一致性。我们把这两种一致性，称为“全局一致性”（注意不是全局读一致性哦）。 分布式读一致性（即全局读一致性），从外部用户的视角，观察数据库内部发生的事件产生的结果之间的顺序要与事件发生的实际顺序保持一致，不能A事件先于B事件发生，但先不到B事件的结果后才可能看到A事件的影响。
14.4K31发布于 2019-05-16 - 来自专栏windealli
一致性无锁读与MVCC、undo-log、Read-View
一致性无锁读什么是一致性无锁读一致性无锁读包含两层含义：一致性读无锁一致性读一致性读，即快照读。在InnoDB中，事务中的查询会基于某个时间点创建的快照返回结果集，而非查询数据库表空间中的当前数据。 一致性读（MySQL官方文档）。 一致性读与当前读相对立：一致性读： 基于快照返回结果集， 普通的select即使用一致性读。 在RR隔离级别下： 事务中的第一次一致性读（时间点）会创建一个快照，然后这个事务中后续所有的一致性读都基于这个快照返回数据。 （除非本事务自己修改了相关数据）在RC隔离级别下： 事务每一次一致性读，都会重置快照。无锁的一致性读InnoDB，普通的select读操作是不会对记录加锁的，否则就会产生比较大的性能开销。 基于MVCC、Read-View、Undo-log实现一致性无锁读有了前面的基础知识，我们来看下如何基于MVCC、Read-View、undo-log实现一致性无锁读。
1.6K180编辑于 2022-09-21 - 来自专栏数据和云
补偏救弊 | 关于一致性读与语句性能关系的一大误区
个人网站 www.HelloDBA.com 研究背景 实际上，我们所说的保证同一时间点一致性读的概念，其背后是物理层面的 block 读，Oracle 会依据你发出 select 命令，记录下那一刻的 SCN 值，然后以这个 SCN 值去同所读的每个 block 上的 SCN 比较，如果读到的块上的 SCN 大于 select 发出时记录的 SCN，则需要利用 Undo 得到该 block 的前镜像， 一致性读（Consistent Gets，CG）是反映 SQL 语句性能的一项重要数据。它通常作为我们语句调优的指标。一般情况下，通过该数据可以比较两条语句或者同一语句的不同执行计划之间的性能。
84840发布于 2018-03-05 - 来自专栏数据库新发现
补偏救弊 | 关于一致性读与语句性能关系的一大误区
实际上，我们所说的保证同一时间点一致性读的概念，其背后是物理层面的 block 读，Oracle 会依据你发出 select 命令，记录下那一刻的 SCN 值，然后以这个 SCN 值去同所读的每个 block 一致性读（Consistent Gets，CG）是反映 SQL 语句性能的一项重要数据。它通常作为我们语句调优的指标。一般情况下，通过该数据可以比较两条语句或者同一语句的不同执行计划之间的性能。
47220发布于 2019-05-26 - 来自专栏windealli
深入浅出： MySQL中的一致性无锁读与MVCC魔法
一致性无锁读包含两层含义： 一致性读 无锁 一致性读 一致性读，即快照读。在InnoDB中，事务中的查询会基于某个时间点创建的快照返回结果集，而非查询数据库表空间中的当前数据。 一致性读（MySQL官方文档）。 一致性读与当前读相对立： 一致性读： 基于快照返回结果集， 普通的select即使用一致性读。 在RR隔离级别下： 事务中的第一次一致性读（时间点）会创建一个快照，然后这个事务中后续所有的一致性读都基于这个快照返回数据。 如何通过MVCC实现一致性无锁读 MVCC实现一致性无锁读的关键在于，它允许读事务访问数据的旧版本，而写事务则创建新的数据版本。 幻读问题在RR隔离级别下仍然可能出现。 ” Undo Log与一致性无锁读 Undo Log是MVCC实现一致性无锁读的基石。
56710编辑于 2024-03-11 - 来自专栏AustinDatabases
PolarDB 卷来卷去 云原生低延迟强一致性读 1 （SCC READ 译 ）
基于许多应用程序，强一致读中的严格一致性的要求，如果不能保证一致性已经下单的用户会发现订单不存在或支付未显示而产生业务错误的问题，对于强一致的要求在一些应用程序是有体现的。 这里有两种直接设计方案，可以支持RO节点上一致性读取，1 commitwait ,2 readwait,这里两种方案，方案1 需要进行实物COMMIT时等待数据传输到从节点 而方案2 需要读请求等待读节点接受到主节点的时间戳并确认数据事务执行后 这两种方案都是以性能作为牺牲而达到的最终一致性。 基于这些设计，POLARDB-SCC 在RO节点上实现了低延迟和强一致性读取，为应用程序提供了具有强一致性的保证的代理端点，并以负载均衡的方式将读请求发送给RO节点，通过动态的增加RO节点来实现读写分离的弹性需求 他会将该时间戳与获取操作的起始时间的时间戳用组合的方式来进行保存，通过这样的设计满足当一个RO节点上请求需要RW节点的时间戳，他将检测RO节点上的元组，如果请求达到时间早于时间戳则可以利用本地的缓存，否则就需要刷新缓存确保读的一致性
47120编辑于 2023-11-07 - 来自专栏爱可生开源社区
故障分析 | 从慢日志问题看 MySQL 半一致性读的应用场景
因为 RC 模式下支持半一致性读。 什么是半一致性读呢？ 简单来说就是当要对行进行加锁时，会多一步判断该行是不是真的需要上锁。 比如全表扫描更新的时候，我们只需要更新 WHERE 匹配到的行，如果是没有半一致性读就会把所有数据进行加锁，但是有了半一致性读，那么会判断是否满足 WHERE 条件，若不满足则不会加锁（提前释放锁）。 那么对于区分度低的字段就可以使用半一致性读特性来优化，这样更新不同的值就不会互相等待，导致业务卡顿。 * 建议用电脑端查看。 半一致性读是基于 RC 隔离级别的优化，可以减少锁冲突以及锁等待，提升并发。 本文关键字：#MySQL# #InnoDB# #事务# #锁#
37710编辑于 2023-08-18 - 来自专栏PingCAP的专栏
读 TiDB 论文有感 | 数据强一致性且资源隔离的 HTAP 数据库
这是从数据库系统外部通过异构系统来解决这一个问题，牺牲了数据的实时性和一致性，在论文中，TiDB 提出了一个新的方案，从数据库系统内部来解决这个问题，同时避免数据的实时性和一致性的丢失。 一般来说，对于一个分布式存储系统，数据强一致性和资源相互隔离经常是一个二选一的选择题，选择数据强一致性，一般是通过同步复制的方式（比如同步双写等）将数据复制到多个相关的实例上，那么将导致所有的计算与存储资源都会紧耦合在一个系统中 到这里，大家可能会发现一个问题，TiFlash 的 Learner 角色是异步接受 Raft Group 的 Raft Log，那么怎么保证 TiFlash 的数据强一致性呢？ 这样，TiDB 就将同步的数据复制机制转变成异步的数据复制机制了，并且保证了数据的强一致性。 并且这个数据的延迟不会影响 TiFlash 的一致性级别，只会让 TiFlash 上的请求稍微慢一点，因为接受到读请求的时候需要去做一次数据同步。
1.2K41发布于 2020-09-10
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号