>  기사  >  데이터 베이스  >  전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

coldplay.xixi
coldplay.xixi앞으로
2020-09-16 16:37:0643799검색


전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

관련 학습 권장 사항: mysql 튜토리얼

MVCC란 무엇입니까

전체 이름은 Multi-Version Concurrency Control, 주로 다중 버전 동시성 제어입니다. 데이터베이스 동시성 성능의 성능을 향상합니다. myIsam은 트랜잭션을 지원하지 않기 때문에 다음 기사는 모두 InnoDB 엔진에 관한 것입니다. 多版本并发控制,主要是为了提高数据库的并发性能。以下文章都是围绕InnoDB引擎来讲,因为myIsam不支持事务。

同一行数据平时发生读写请求时,会上锁阻塞住。但mvcc用更好的方式去处理读—写请求,做到在发生读—写请求冲突时不用加锁

这个读是指的快照读,而不是当前读,当前读是一种加锁操作,是悲观锁

那它到底是怎么做到读—写不用加锁的,快照读当前读又是什么鬼,跟着你们的贴心老哥,继续往下看。

전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

当前读、快照读都是什么鬼

什么是MySQL InnoDB下的当前读和快照读?

当前读

它读取的数据库记录,都是当前最新版本,会对当前读取的数据进行加锁,防止其他事务修改数据。是悲观锁的一种操作。

如下操作都是当前读:

  • select lock in share mode (共享锁)

  • select for update (排他锁)

  • update (排他锁)

  • insert (排他锁)

  • delete (排他锁)

  • 串行化事务隔离级别

快照读

快照读的实现是基于多版本并发控制,即MVCC,既然是多版本,那么快照读读到的数据不一定是当前最新的数据,有可能是之前历史版本的数据。

如下操作是快照读:

  • 不加锁的select操作(注:事务级别不是串行化)

快照读与mvcc的关系

MVCCC是“维持一个数据的多个版本,使读写操作没有冲突”的一个抽象概念

这个概念需要具体功能去实现,这个具体实现就是快照读。(具体实现下面讲)

听完贴心老哥的讲解,是不是瞬间茅厕顿开

전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

数据库并发场景

  • 读-读:不存在任何问题,也不需要并发控制

  • 读-写:有线程安全问题,可能会造成事务隔离性问题,可能遇到脏读,幻读,不可重复读

  • 写-写:有线程安全问题,可能会存在更新丢失问题,比如第一类更新丢失,第二类更新丢失

MVCC解决并发哪些问题?

mvcc用来解决读—写冲突的无锁并发控制,就是为事务分配单向增长时间戳。为每个数据修改保存一个版本,版本与事务时间戳相关联

读操作只读取该事务开始前数据库快照

解决问题如下:

  • 并发读-写时:可以做到读操作不阻塞写操作,同时写操作也不会阻塞读操作。

  • 解决脏读幻读不可重复读等事务隔离问题,但不能解决上面的写-写 更新丢失问题。

因此有了下面提高并发性能的组合拳

  • MVCC + 悲观锁:MVCC解决读写冲突,悲观锁解决写写冲突

  • MVCC + 乐观锁:MVCC解决读写冲突,乐观锁解决写写冲突

MVCC的实现原理

它的实现原理主要是版本链undo日志Read View 来实现的

版本链

我们数据库中的每行数据,除了我们肉眼看见的数据,还有几个隐藏字段,得开天眼才能看到。分别是db_trx_iddb_roll_pointerdb_row_id

동일한 데이터 행에 대해 읽기 또는 쓰기 요청이 발생하면 잠금 및 차단됩니다. 그러나 mvcc는 읽기-쓰기 요청을 처리하는 더 나은 방법을 사용하므로 읽기-쓰기 요청 충돌이 발생할 때 잠금이 필요하지 않습니다.
  • 이 읽기는 현재 읽기가 아닌 스냅샷 읽기를 나타냅니다. 현재 읽기는 잠금 작업, 즉 비관적 잠금입니다.

    그렇다면 어떻게 잠금 없이 읽기와 쓰기를 달성할 수 있나요? 스냅샷 읽기현재 읽기는 무엇인가요? >, 계속 읽어보세요. 🎜전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

    현재 읽기 및 스냅샷 읽기란 무엇입니까? 🎜🎜MySQL InnoDB의 현재 읽기 및 스냅샷은 무엇입니까? 읽다? 🎜

    현재 읽기

    🎜읽는 데이터베이스 기록은 모두 현재 최신 버전입니다. 다른 트랜잭션이 데이터를 수정하지 못하도록 읽기 데이터가 잠겨 있습니다. 비관적 잠금 작업입니다. 🎜🎜다음 작업은 모두 현재 읽기입니다. 🎜🎜🎜🎜공유 모드에서 잠금 선택(공유 잠금)🎜
  • 🎜🎜업데이트 선택(독점 잠금)🎜🎜🎜업데이트(독점 잠금)🎜 🎜🎜삽입(독점 잠금)🎜🎜🎜삭제(독점 잠금)🎜🎜🎜직렬화된 트랜잭션 격리 수준🎜

스냅샷 읽기

🎜스냅샷 읽기 구현은 다중 버전 동시성 제어, 즉 MVCC를 기반으로 합니다. 다중 버전이기 때문에 스냅샷으로 읽은 데이터는 읽는 것이 반드시 최신 데이터는 아닙니다. 최신 데이터는 이전 과거 버전의 데이터일 수 있습니다. 🎜🎜다음 작업은 스냅샷 읽기입니다. 🎜🎜🎜잠금 없이 작업 선택(참고: 트랜잭션 수준은 직렬화되지 않음)

스냅샷 읽기와 관계 mvcc의

🎜MVCCC는 "읽기 및 쓰기 작업에 충돌이 없도록 여러 버전의 데이터를 유지 관리"하는 추상적인 개념입니다. 🎜🎜이 개념을 구현하려면 특정 기능이 필요하며, 이 특정 구현은 스냅샷 읽기입니다. (구체적인 구현은 아래에서 논의) 🎜🎜사려깊은 형의 설명을 듣고 있는데 화장실이 갑자기 열렸나요? 🎜전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

데이터베이스 동시성 시나리오 🎜🎜🎜🎜읽기-읽기: 없음 문제가 있으며 동시성 제어가 필요하지 않습니다🎜🎜🎜읽기-쓰기: 스레드 안전 문제가 있어 트랜잭션 격리 문제를 일으킬 수 있으며 더티 읽기, 팬텀 읽기 및 비 읽기가 발생할 수 있습니다. -반복 읽기 🎜🎜🎜Write-Write: 스레드 안전 문제가 있으며 첫 번째 유형의 업데이트 손실, 두 번째 유형의 업데이트 손실과 같은 업데이트 손실 문제가 있을 수 있습니다🎜

MVCC는 어떤 동시성 문제를 해결합니까? 🎜🎜읽기-쓰기 충돌을 해결하기 위해 mvcc에서 사용하는 잠금 없는 동시성 제어는 한 방향으로 증가하는 타임스탬프를 트랜잭션에 할당하는 것입니다. 각 데이터 수정에 대해 버전이 저장되며 버전은 거래 타임스탬프와 연결됩니다. 🎜🎜읽기 작업은 트랜잭션이 시작되기 전에 데이터베이스 스냅샷읽기만합니다. 🎜🎜문제는 다음과 같이 해결됩니다.🎜🎜🎜🎜동시 읽기-쓰기: 쓰기 작업을 차단하지 않고 읽기 작업을 수행할 수 있으며 쓰기 작업은 수행되지 않습니다. 읽기 작업을 차단합니다. 🎜🎜🎜 더티 읽기, 팬텀 읽기, 반복 불가능한 읽기와 같은 트랜잭션 격리 문제를 해결하지만 위의 문제는 해결할 수 없습니다. 쓰기-쓰기 업데이트가 손실되었습니다 문제. 🎜🎜동시성 성능을 향상시키기 위한 다음 조합 펀치가 있습니다:🎜🎜🎜🎜MVCC + 비관적 잠금 : MVCC는 읽기-쓰기 충돌을 해결하고 비관적 잠금은 쓰기-쓰기 충돌을 해결합니다🎜🎜🎜MVCC + 낙관적 잠금: MVCC는 읽기-쓰기 충돌을 해결하고 낙관적 잠금은 쓰기-쓰기 충돌을 해결합니다🎜

MVCC의 구현 원칙🎜🎜구현 원칙은 주로 버전 체인, <code>실행 취소 로그, 읽기 보기 가 구현되었습니다 🎜

버전 체인

🎜로 볼 수 있는 데이터 외에도 데이터베이스의 모든 데이터 행 육안으로는 숨겨진 필드가 여러 개 있는데 Sky Eye를 열어야 볼 수 있습니다. db_trx_id, db_roll_pointer, db_row_id입니다. 🎜🎜🎜🎜db_trx_id🎜

6byte, 최근 수정(수정/삽입) 거래 ID: 이 레코드의 생성 기록/이 거래의 <code>마지막 수정 레코드 ID. 事务ID:记录创建这条记录/最后一次修改该记录的事务ID

  • db_roll_pointer(版本链关键)

    7byte,回滚指针,指向这条记录上一个版本(存储于rollback segment里)

  • db_row_id

    6byte,隐含的自增ID(隐藏主键),如果数据表没有主键,InnoDB会自动以db_row_id产生一个聚簇索引

  • 实际还有一个删除flag隐藏字段, 记录被更新删除并不代表真的删除,而是删除flag变了

  • 전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

    如上图,db_row_id是数据库默认为该行记录生成的唯一隐式主键db_trx_id是当前操作该记录的事务ID,而db_roll_pointer是一个回滚指针,用于配合undo日志,指向上一个旧版本

    每次对数据库记录进行改动,都会记录一条undo日志,每条undo日志也都有一个roll_pointer属性(INSERT操作对应的undo日志没有该属性,因为该记录并没有更早的版本),可以将这些undo日志都连起来串成一个链表,所以现在的情况就像下图一样:

    전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

    对该记录每次更新后,都会将旧值放到一条undo日志中,就算是该记录的一个旧版本,随着更新次数的增多,所有的版本都会被roll_pointer属性连接成一个链表,我们把这个链表称之为版本链,版本链的头节点就是当前记录最新的值。另外,每个版本中还包含生成该版本时对应的事务id,这个信息很重要,在根据ReadView判断版本可见性的时候会用到。

    undo日志

    Undo log 主要用于记录数据被修改之前的日志,在表信息修改之前先会把数据拷贝到undo log里。

    事务进行回滚时可以通过undo log 里的日志进行数据还原

    Undo log 的用途

    • 保证事务进行rollback时的原子性和一致性,当事务进行回滚的时候可以用undo log的数据进行恢复

    • 用于MVCC快照读的数据,在MVCC多版本控制中,通过读取undo log历史版本数据可以实现不同事务版本号都拥有自己独立的快照数据版本

    undo log主要分为两种:

    • insert undo log

      代表事务在insert新记录时产生的undo log , 只在事务回滚时需要,并且在事务提交后可以被立即丢弃

    • update undo log(主要)

      事务在进行update或delete时产生的undo log ; 不仅在事务回滚时需要,在快照读时也需要;

      所以不能随便删除,只有在快速读或事务回滚不涉及该日志时,对应的日志才会被purge线程统一清除

    Read View(读视图)

    事务进行快照读操作的时候生产的读视图(Read View),在该事务执行的快照读的那一刻,会生成数据库系统当前的一个快照

    记录并维护系统当前活跃事务的ID(没有commit,当每个事务开启时,都会被分配一个ID, 这个ID是递增的,所以越新的事务,ID值越大),是系统中当前不应该被本事务看到的其他事务id列表

    Read View主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候,对该记录创建一个Read View读视图,把它比作条件用来判断当前事务能够看到哪个版本的数据,既可能是当前最新的数据,也有可能是该行记录的undo log里面的某个版本的数据。

    Read View几个属性

    • trx_ids: 当前系统活跃(未提交)事务版本号集合。

    • low_limit_id: 创建当前read view 时“当前系统最大事务版本号

    • db_roll_pointer(버전 체인 키) 🎜🎜7byte, 이 레코드이전 버전을 가리키는 롤백 포인터 > code> (롤백 세그먼트에 저장됨) 🎜
    • 🎜db_row_id🎜🎜6byte, 암시적 자동 증가 ID(숨겨진 기본 키), 데이터 테이블 가 그렇지 않은 경우 기본 키가 있으면 InnoDB는 db_row_id를 기반으로 <code>클러스터형 인덱스를 자동으로 생성합니다. 🎜
    • 🎜실제로는 삭제 플래그 숨겨진 필드가 있습니다. 단지 레코드가 업데이트되거나 삭제되었다고 해서 의미가 있는 것은 아닙니다. 실제로는 삭제되었지만 삭제 플래그가 변경되었습니다🎜
    전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.
    🎜위와 같이 db_row_id는 이 레코드 행에 대해 데이터베이스에서 기본적으로 생성하는 고유 암시적 기본 키이고, db_trx_id트랜잭션 ID입니다. 레코드의 현재 작업이고 db_roll_pointer는 <code>실행 취소 로그와 함께 사용되는 롤백 포인터이며 이전 이전 버전. 🎜🎜데이터베이스 레코드가 수정될 때마다 <code>실행 취소 로그가 기록됩니다. 각 실행 취소 로그에는 roll_pointer 속성도 있습니다(INSERT 작업에 해당하는 실행 취소 로그는 그렇지 않습니다). 레코드에 이전 버전이 없기 때문에 이 속성이 있습니다) 이러한 <code>실행 취소 로그를 연결하고 연결된 목록에 연결할 수 있으므로 현재 상황은 그림과 같습니다. 아래: 🎜전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.
    🎜레코드가 업데이트될 때마다 이전 값은 이전 버전의 레코드라도 실행 취소 로그에 저장됩니다. 업데이트 수가 증가하면 모든 버전이 roll_pointer 속성에 의해 연결 목록에 연결됩니다. 우리는 이 연결 목록을 버전 체인이라고 부릅니다. 버전 체인의 헤드 노드는 현재 레코드의 최신 값입니다. 또한 각 버전에는 버전이 생성되었을 때 해당 트랜잭션 ID도 포함되어 있습니다. 이 정보는 매우 중요하며 ReadView를 기반으로 버전의 가시성을 판단할 때 사용됩니다. 🎜

    실행 취소 로그

    🎜실행 취소 로그는 주로 데이터가 수정되기 전의 로그를 기록하는 데 사용됩니다. 테이블 정보 수정 전 해당 데이터는 undo log에 복사됩니다. 🎜🎜트랜잭션롤백되면 로그인 취소 로그를 통해 데이터 복원이 가능합니다. 🎜🎜실행 취소 로그의 목적🎜
    • 🎜 트랜잭션롤백 /code>을 수행할 때 원자성과 일관성롤백되면 실행 취소 로그 데이터를 복구하는 데 사용할 수 있습니다. 🎜
    • 🎜 MVCC 다중 버전 제어에서 <code>실행 취소 로그의 이전 버전 데이터를 읽어 MVCC 스냅샷 읽기에 사용되는 데이터입니다. 서로 다른 거래 버전 번호에는 고유한 독립적인 스냅샷 데이터 버전이 있다는 것을 알 수 있습니다. 🎜
    🎜실행 취소 로그는 크게 두 가지 유형으로 나뉩니다. 🎜
    • 🎜insert undo log🎜🎜는 트랜잭션이 새 로그를 삽입할 때 생성되는 실행 취소 로그를 나타냅니다. 기록, 트랜잭션이 롤백될 때만 필요하며 트랜잭션이 커밋된 후 즉시 삭제될 수 있습니다🎜
    • 🎜update undo log (main)🎜🎜트랜잭션이 업데이트되거나 삭제될 때 생성되는 undo 로그; 트랜잭션이 롤백될 때뿐만 아니라 롤백할 때도 필요하고, 스냅샷을 읽을 때도 필요합니다. 🎜🎜그래서 로그가 빠른 읽기나 트랜잭션 롤백에 관련되지 않은 경우에만 해당 로그가 삭제됩니다. 퍼지 스레드에 의해 균일하게 삭제됩니다🎜

    읽기 보기

    🎜트랜잭션이 수행될 때 생성되는 읽기 보기 스냅샷 읽기 작업( 읽기 보기)은 트랜잭션에 의해 실행된 스냅샷을 읽는 순간 데이터베이스 시스템의 현재 스냅샷이 생성됩니다. 🎜🎜시스템의 현재 활성 트랜잭션 ID를 기록하고 유지합니다(커밋하지 않고 각 트랜잭션이 시작될 때 ID가 할당됩니다. 이 ID는 증가하므로 트랜잭션이 최신일수록 더 높아집니다. ID 값. 대형)은 현재 이 거래에서 볼 수 없는 시스템의 다른 거래 ID 목록입니다. 🎜🎜Read View는 주로 visibility 판단에 사용됩니다. 즉, 특정 트랜잭션스냅샷 읽기를 수행할 때 레코드가 Read View를 생성하고 현재 거래가 볼 수 있는 데이터 버전을 결정하는 조건과 비교합니다. 이는 현재 최신일 수 있습니다. > 데이터는 특정 버전이 행에 기록된 실행 취소 로그에 있습니다. 🎜🎜읽기 보기의 여러 속성🎜
    • 🎜trx_ids: 현재 시스템. 🎜
    • 🎜low_limit_id: 현재 읽기 보기를 생성할 때 "현재 시스템 최대 트랜잭션 버전 번호+1"입니다. 🎜
    • up_limit_id: 현재 읽기 보기를 생성할 때 "시스템이 활성 트랜잭션 최소 버전 번호에 있습니다." up_limit_id: 创建当前read view 时“系统正处于活跃事务最小版本号

    • creator_trx_id: 创建当前read view的事务版本号;

    Read View可见性判断条件

    • db_trx_id < up_limit_id || db_trx_id == creator_trx_id(显示)

      如果数据事务ID小于read view中的最小活跃事务ID,则可以肯定该数据是在当前事务启之前就已经存在了的,所以可以显示

      或者数据的事务ID等于creator_trx_id ,那么说明这个数据就是当前事务自己生成的,自己生成的数据自己当然能看见,所以这种情况下此数据也是可以显示的。

    • db_trx_id >= low_limit_id(不显示)

      如果数据事务ID大于read view 中的当前系统的最大事务ID,则说明该数据是在当前read view 创建之后才产生的,所以数据不显示。如果小于则进入下一个判断

    • db_trx_id是否在活跃事务(trx_ids)中

      • 不存在:则说明read view产生的时候事务已经commit了,这种情况数据则可以显示

      • 已存在:则代表我Read View生成时刻,你这个事务还在活跃,还没有Commit,你修改的数据,我当前事务也是看不见的。

    전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

    MVCC和事务隔离级别

    上面所讲的Read View用于支持RC(Read Committed,读提交)和RR(Repeatable Read,可重复读)隔离级别实现

    RR、RC生成时机

    • RC隔离级别下,是每个快照读都会生成并获取最新Read View

    • 而在RR隔离级别下,则是同一个事务中第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View,之后的查询就不会重复生成了,所以一个事务的查询结果每次都是一样的

    解决幻读问题

    • 快照读:通过MVCC来进行控制的,不用加锁。按照MVCC中规定的“语法”进行增删改查等操作,以避免幻读。

    • 当前读:通过next-key锁(行锁+gap锁)来解决问题的。

    RC、RR级别下的InnoDB快照读区别

    • 在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View, 将当前系统活跃的其他事务记录起来,此后在调用快照读的时候,还是使用的是同一个Read View,所以只要当前事务在其他事务提交更新之前使用过快照读,那么之后的快照读使用的都是同一个Read View,所以对之后的修改不可见;

    • 即RR级别下,快照读生成Read View时,Read View会记录此时所有其他活动事务的快照,这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见

    • 而在RC级别下的,事务中,每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因

    总结

    从以上的描述中我们可以看出来,所谓的MVCC指的就是在使用READ COMMITTDREPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程,这样子可以使不同事务的读-写写-读操作并发执行,从而提升系统性能

    creator_trx_id: 생성 중 현재 읽기 보기의 트랜잭션 버전 번호

    읽기 보기 가시성 판단 조건

    Figure>

      db_trx_id < up_limit_id || db_trx_id == creator_trx_id (표시)
    🎜 데이터 트랜잭션 ID가 읽기 보기의 최소 활성 트랜잭션 ID보다 작은 경우 현재 트랜잭션이 완료되기 전에 데이터가 이미 <code>존재하는지 확인할 수 있습니다. 시작되어 표시할 수 있습니다. 🎜🎜 또는 데이터의 트랜잭션 IDcreator_trx_id와 동일하면 데이터가 현재 트랜잭션에 의해 생성되고 자신이 생성한 데이터는 물론 본인도 볼 수 있으므로 이 경우 이 데이터도 표시될 수 있습니다. 🎜🎜🎜🎜db_trx_id >= low_limit_id (표시되지 않음) 🎜🎜데이터 트랜잭션 ID가 읽기 중인 현재 시스템의 최대 트랜잭션 ID보다 큰 경우 view는 현재 읽기 뷰가 생성된 후에 데이터가 생성된다는 의미이므로 데이터가 표시되지 않습니다. 미만이면 다음 판단으로 🎜🎜🎜🎜db_trx_id active transaction(trx_ids)에 있는지 여부 🎜
      🎜🎜않음 존재: 읽기 뷰가 생성될 때 트랜잭션이 커밋되었음을 의미합니다. 이 경우 데이터가 표시될 수 있습니다. 🎜🎜🎜🎜존재: 읽기 보기가 생성될 때 귀하의 트랜잭션이 여전히 활성 상태이고 아직 커밋되지 않았음을 의미합니다. 수정한 데이터도 현재 트랜잭션에 표시되지 않습니다. 🎜🎜
    🎜 전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.

    MVCC 및 트랜잭션 격리 수준

    🎜위 언급된 읽기 보기RC(읽기 커밋, 읽기 제출) 및 RR(반복 읽기, 반복 읽기)를 지원하는 데 사용됩니다. 격리 수준 구현. 🎜

    RR 및 RC 생성 타이밍

      🎜🎜RC격리 수준에서 각 스냅샷 읽기 최신 읽기 보기를 생성하고 얻습니다. 🎜🎜🎜🎜 그리고 RR 격리 수준에서는 동일한 트랜잭션입니다. code>읽기 보기는 에서 첫 번째 스냅샷 읽기 후에만 생성됩니다. 이후 스냅샷 읽기는 동일한 결과를 얻습니다. 읽기 보기를 사용하면 후속 쿼리가 반복적으로 생성되지 않으므로 트랜잭션의 쿼리 결과가 매번 동일됩니다. 🎜🎜

    팬텀 읽기 문제 해결

      🎜🎜스냅샷 읽기: MVCC를 통해 제어되며 추가할 필요가 없습니다. 잠그다. 환상 읽기를 방지하려면 MVCC에 지정된 "문법"에 따라 추가, 삭제, 수정, 검색 등의 작업을 수행하세요. 🎜🎜🎜🎜현재 읽기: 다음 키 잠금(행 잠금 + 간격 잠금)을 통해 문제가 해결됩니다. 🎜🎜

    RC 수준과 RR 수준의 InnoDB 스냅샷 읽기 차이

      🎜🎜RR 수준의 특정 트랜잭션에 대한 특정 기록 첫 번째 스냅샷 읽기는 스냅샷과 읽기 보기를 생성하여 현재 시스템에서 활성화된 다른 트랜잭션을 기록합니다. 그 후 스냅샷 읽기를 호출할 때 현재 트랜잭션이 다른 트랜잭션에서 업데이트를 커밋하는 한 동일한 읽기 보기가 계속 사용됩니다. 이전에 스냅샷 읽기를 사용한 경우 후속 스냅샷 읽기는 동일한 읽기 보기를 사용하므로 후속 수정 사항은 표시되지 않습니다. 🎜🎜🎜🎜즉, RR 수준에서는 스냅샷 읽기가 읽기 보기를 생성할 때, 보기는 이 시간을 기록합니다. 수정 사항이 현재 트랜잭션에 표시되지 않는 다른 모든 활성 트랜잭션의 스냅샷입니다. 읽기 보기 이전에 생성된 트랜잭션에 의해 수정된 내용은 모두 표시됩니다.🎜🎜🎜🎜RC 수준에서는 트랜잭션에서 각 스냅샷 읽기가 새로운 스냅샷과 읽기 보기를 생성합니다. 이것이 RC 수준에서 수행할 수 있는 작업입니다. 트랜잭션에서 다른 트랜잭션이 제출한 업데이트 이유를 확인하세요🎜🎜

    요약

    🎜위 설명에서 소위 MVCC라는 것을 알 수 있습니다. READ COMMITTDREPEATABLE READ라는 두 가지 격리 수준 트랜잭션을 사용하여 일반적인 SEELCT 작업을 수행할 때 기록되는 를 의미합니다. 버전 체인 프로세스를 통해 이러한 방식으로 다양한 트랜잭션의 읽기-쓰기쓰기-읽기 작업을 동시에 실행할 수 있습니다. , 따라서 시스템 성능을 향상합니다. 🎜🎜🎜프로그래밍 학습에 대해 더 자세히 알고 싶다면 🎜php training🎜 칼럼을 주목해주세요! 🎜🎜🎜

    위 내용은 전체 네트워크에서 가장 완벽한 데이터베이스 MVCC로, 불완전한 설명에 대한 책임은 본인에게 있습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

    성명:
    이 기사는 juejin.im에서 복제됩니다. 침해가 있는 경우 admin@php.cn으로 문의하시기 바랍니다. 삭제