Comment MySQL résout-il le problème de lecture fantôme ? L’article suivant vous permettra d’aborder cette problématique. Lisons l’article avec des questions !
Parmi les questions d'entretien très fréquentes de Jin Bu San et Yin Bu Si, les caractéristiques des transactions de MySQL, le niveau d'isolement et d'autres problèmes sont également l'un des essais en huit parties les plus classiques. On estime que la plupart des amis pourront le récupérer facilement. Choses :
Caractéristiques de la transaction (ACID) : Atomicité
(Atomicité
), . Isolement
(Isolement
>), Cohérence
et Persistance
原子性
(Atomicity
)、隔离性
(Isolation
)、一致性
(Consistency
)和持久性
隔离级别:读取未提交
(READ UNCOMMITTED
),读取已提交
(READ COMMITTED
),可重复读
(REPEATABLE READ
),可串行化
(SERIALIZABLE
)
而每一种隔离级别导致的问题有:
READ UNCOMMITTED
隔离级别下,可能发生脏读
、不可重复读
和幻读
问题READ COMMITTED
隔离级别下,可能发生不可重复读
和幻读
问题,但是不可以发生脏读
问题REPEATABLE READ
隔离级别下,可能发生幻读
问题,但是不可以发生脏读
和不可重复读
的问题SERIALIZABLE
隔离级别下,各种问题都不可以发生对于MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ(可重读),从上面的SQL标准的四种隔离级别定义可知,REPEATABLE-READ(可重复读)
是不可以防止幻读的,但是我们都知道,MySQL InnoDB存储引擎是解决了幻读问题发生的,那他又是如何解决的呢?
在进入主题之前,我们先大致了解一下什么是行格式,这样有助于我们理解下面的MVCC,行格式是表中的行记录在磁盘的存放方式,Innodb
存储引擎总共有4种不同类型的行格式:compact
、redundant
、dynamic
、compress
;虽然很很多行格式,但是在原理上,大体都相同,如下,为compact
行格式: 从图中可以看出来,一条完整的记录其实可以被分为记录的额外信息
和记录的真实数据
两大部分,记录的额外信息
分别是变长字段长度列表
、NULL值列表
和记录头信息
,而记录的真实数据
除了我们自己定义的列之外,MySQL会为每个记录添加一些默认列,这些默认列又称为隐藏列
Les problèmes causés par chaque niveau d'isolement sont : | Pour le stockage MySQL InnoDB Le niveau d'isolement par défaut pris en charge par le Le moteur est | REPEATABLE-READ (répétable) D'après la définition des quatre niveaux d'isolement du standard SQL ci-dessus, on peut voir que REPEATABLE-READ (lecture répétable) ne peut pas être empêché | Lecture fantôme.
---|---|---|
Avant d'entrer dans le sujet, comprenons de manière générale ce qu'est le format de ligne, ce qui nous aidera à comprendre le MVCC suivant, row Le format est la façon dont les enregistrements de ligne dans la table sont stockés sur le disque. Le moteur de stockage Innodb a un total de 4 types différents de formats de ligne : compact , . redondant , dynamic , compress ; bien qu'il existe de nombreux formats de ligne, ils sont fondamentalement les mêmes. Ce qui suit est le compact format de ligne : <img src="https://img.php.cn/upload/article/000/000/024/8dd59fa5971263caaad55b052cdb5754-0.png" alt="Un article analysant brièvement comment MySQL résout le problème de lecture fantôme" chargement="lazy"> Comme Comme le montre l'image, un enregistrement complet peut en fait être divisé en deux parties : les <code>informations supplémentaires enregistrées et les données réelles enregistrées . > sont respectivement Liste de longueur de champ variable , Liste de valeurs NULL et Informations d'en-tête d'enregistrement , et Données réelles enregistrées sauf notre propre définition En plus des colonnes, MySQL ajoutera des colonnes par défaut à chaque enregistrement. Ces colonnes par défaut sont également appelées colonnes cachées . Les colonnes spécifiques sont les suivantes :
|
Nom de la colonne | |
Description | ||
6 octets | ID de ligne, identifie de manière unique un enregistrement |
Nous n'avons pas à nous soucier de la valeur de la colonne cachée. Le moteur de stockage InnoDB
la générera pour nous. Dessinons-la plus en détail. le format est le suivant : InnoDB
存储引擎会自己帮我们生成的,画得再详细一点,compact
行格式如下:
然后将roll_pointer
指向该undolog
,所以该列相当于一个指针,通过该列,可以找到修改之前的信息假设有一条记录如下:插入该记录的事务id
为80
,roll_pointer
指针为NULL(为了便于理解,读者可理解为指向为NULL,实际上roll_pointer第一个比特位就标记着它指向的undo日志的类型,如果该比特位的值为1时,就代表着它指向的undo日志类型为insert undo)
假设之后两个事务id
分别为100
、200
的事务对这条记录进行UPDATE
操作:
-- 事务id=100 update person set grade =20 where id =1; update person set grade =40 where id =1; -- 事务id=200 update person set grade =70 where id =1;
每次对记录进行改动,都会记录一条undo日志
,每条undo日志
也都有一个roll_pointer
属性(INSERT
操作对应的undo日志
没有该属性,因为该记录并没有更早的版本),可以将这些undo日志
都连起来,串成一个链表,所以现在的情况就像下图一样:
对该记录每次更新后,都会将旧值放到一条undo日志
中,就算是该记录的一个旧版本,随着更新次数的增多,所有的版本都会被roll_pointer
属性连接成一个链表,我们把这个链表称之为版本链
,版本链的头节点就是当前记录最新的值。另外,每个版本中还包含生成该版本时对应的事务id
对于数据库的四种隔离级别:1)read uncommitted
;2) read committed
;3) REPEATABLE READ
; 4)SERIALIZABLE
;来说,READ UNCOMMITTED
,每次读取版本链的最新数据即可;SERIALIZABLE
,主要是通过加锁控制;而read committed
和REPEATABLE READ
都是读取已经提交了的事物,所以对于这两个隔离级别,核心问题是版本链中,哪些事物是对当前事物可见;为了解决这个问题,MySQL提出了read view 概念,其包含四个核心概念:
m_ids
:生成read view
时候,活跃的事物id集合min_trx_id
:m_ids的最小值
,既生成read view的时候,活跃事物的最小值max_trx_id
:表示生成read view
的时候,系统应该分配下一个事物id值creator_trx_id
:创建read view
的事物id,即当前事物id。有了这个ReadView
,这样在访问某条记录时,只需要按照下边的步骤判断记录的某个版本是否可见:
creator_trx_id
的时候,说明当前事物正在访问自己修改的记录,所以该版本可见min_trx_id
的时候,则说明,在创建read view
的时候,该事物已经提交,该版本,对当前事物可读max_trx_id
,则说明创建该read view
的时候,该说明生成该版本记录的事物id在生成Read view
之后才开启,所以该版本不能被当前事物可读transaction_id
在m_ids
集合中,说明生成Read view
的时候,该事物还是活跃的,还没有被提交,则该版本不可以被访问;如果不在,则说明创建ReadView
puis roll_pointer
pointe vers le undolog, donc cette colonne équivaut à un pointeur, passé Dans cette colonne, vous pouvez retrouver les informations avant modification🎜<h2 data-id="heading-1">
<strong>Détails MVCC</strong>. </h2>
<h3 data-id="heading-2"> <strong>Chaîne de versions 2.1</strong>
</h3>🎜Supposons qu'il existe un enregistrement comme suit : <img src="https://img.%20php.cn/upload/article/000/000/024/a3789b0f8f8d61a35c454c5a61c58645-2.%20png" alt="Un article analysant brièvement comment MySQL résout le problème de lecture fantôme" chargement="lazy">Le <code>identifiant de transaction
inséré dans cet enregistrement est 80, et le pointeur roll_pointer
est NULL (Pour faciliter la compréhension, les lecteurs peuvent comprendre que le pointeur est NULL. En fait, le premier bit de roll_pointer marque le type de journal d'annulation vers lequel il pointe. Si la valeur de ce bit est 1, il représente le journal d'annulation vers lequel il pointe. Le type est insert undo)🎜🎜Supposons que les deux transactions suivantes avec ID de transaction
soient . 100
et 200
pour METTRE À JOUR cet enregistrement
Opération : 🎜rrreee🎜 Chaque fois qu'un enregistrement est modifié, un undo log
sera enregistré , et chaque undo log
possède également un attribut roll_pointer
code> (le undo log
correspondant à l'opération INSERT
ne n'ont pas cet attribut, car l'enregistrement n'a pas de version antérieure), ces journaux d'annulation
Tous sont connectés et enchaînés dans une liste chaînée, donc la situation actuelle est comme l'image ci-dessous : 🎜🎜 Par conséquent, à chaque fois que l'enregistrement est mis à jour , l'ancienne valeur sera placée dans un undo log
, même s'il s'agit d'une ancienne valeur de l'enregistrement Version, à mesure que le nombre de mises à jour augmente, toutes les versions seront connectées dans une liste chaînée par le roll_pointer. Nous appelons cette liste chaînée chaîne de versions
, le nœud principal de la chaîne de versions. C'est la dernière valeur de l'enregistrement actuel. De plus, chaque version contient également l'ID de transaction
🎜lecture non validée
; 2) lecture validée
3) LECTURE REPEATABLE
4)SERIALIZABLE
; ; Par exemple, READ UNCOMMITTED
n'a besoin de lire que les dernières données de la chaîne de versions à chaque fois ; SERIALIZABLE
est principalement contrôlé par le verrouillage et read commit
; > et REPEATABLE READ
lisent tous deux les éléments validés, donc pour ces deux niveaux d'isolement, le problème principal est de savoir quels éléments de la chaîne de versions sont visibles par l'élément actuel afin de résoudre ce problème, MySQL a proposé le ; concept de vue en lecture, qui contient quatre concepts de base : 🎜m_ids
: lors de la génération de la vue en lecture
, l'ID de l'objet actif est défini 🎜min_trx_id
: La valeur minimale de m_ids
, qui est la valeur minimale des éléments actifs lors de la génération de la vue en lecture🎜max_trx_id
: Indique que lors de la génération de lire la vue, le système doit attribuer la valeur d'identifiant d'objet suivante 🎜creator_trx_id
: créer l'identifiant d'objet de lire la vue
, c'est-à-dire le identifiant de l'objet actuel. 🎜🎜🎜Avec ce ReadView
, lors de l'accès à un enregistrement, il vous suffit de suivre les étapes ci-dessous pour déterminer si une certaine version de l'enregistrement est visible : 🎜min_trx_id
, cela signifie que lors de la création de read view, l'objet a été soumis et cette version est lisible pour l'objet actuel🎜max_trx_id, cela signifie qu'il est créé. Lorsque <code>read view
est généré, cela signifie que l'ID d'objet qui génère cet enregistrement de version n'est pas ouvert tant que Read view
n'est pas généré, donc cette version ne peut pas être lue par l'objet actuel🎜transaction_id
est dans la collection m_ids
, cela signifie que lorsque Lire la vue code> est généré, la transaction est toujours active et n'a pas encore été soumise, alors cette version n'est pas accessible sinon, cela signifie que la transaction qui a généré cette version lors de la création de <code>ReadView
a été soumise ; et accessible🎜🎜🎜Remarque : l'ID de l'objet lu est 0🎜Dans MySQL
, une très grande différence entre les niveaux d'isolement de READ COMMITTED
et REPEATABLE READ
est qu'ils génèrent ReadView à des moments différents : MySQL
中,READ COMMITTED
和REPEATABLE READ
隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同:
READ COMMITTED
—— 每次读取数据前都生成一个ReadView
REPEATABLE READ
—— 在第一次读取数据时生成一个ReadView
下面我们通过详细例子来说明,两者有何不同:
时间编号 | trx 100 | trx 200 | |
---|---|---|---|
① | BEGIN; | ||
② | BEGIN; | BEGIN; | |
③ | update person set grade =20 where id =1; | ||
④ | update person set grade =40 where id =1; | ||
⑤ | SELECT * FROM person WHERE id = 1; | ||
⑥ | COMMIT; | ||
⑦ | update person set grade =70 where id =1; | ||
⑧ | SELECT * FROM person WHERE id = 1; | ||
⑨ | COMMIT; | ||
? | COMMIT; |
在时间④中,因事务trx 100
执行了事务的提交,id=1行记录的版本链如下:
在时间⑥中,因事务trx 200
执行了事务的提交,id=1行记录的版本链如下:
在时间⑤,事务trx 100
执行select
语句时会先生成一个ReadView
,ReadView
的m_ids
列表的内容就是[100, 200]
,min_trx_id
为100
,max_trx_id
为201
,creator_trx_id
为0
,此时,从版本链中选可见的记录,版本链从上到下遍历:因为grade=40,trx_id
值为100
,在m_ids
里,所以该记录不可见,同理,grade=20的也不见。继续往下遍历,grade=20,trx_id
值为80
,小于小于ReadView
中的min_trx_id
值100
,所以这个版本符合要求,返回给用户的是等级为10的记录。
在时间⑧中,如果事务的隔离级别是READ COMMITTED
,会单独又生成一个ReadView
,该ReadView
的m_ids
列表的内容就是[200]
,min_trx_id
为200
,max_trx_id
为201
,creator_trx_id
为0
,此时,从版本链中选可见的记录,版本链从上到下遍历:因为grade=70,trx_id
值为200
,在m_ids
里,所以该记录不可见,继续往下遍历,grade=40,trx_id
值为100
,小于ReadView
中的min_trx_id
值200
,所以这个版本是符合要求的,返回给用户的是是等级为40的记录。
在时间⑧中,如果事务的隔离级别是 REPEATABLE READ
,在时间⑧中,不会单独生成一个ReadView
,而是沿用时间5的ReadView
,所以返回给用户的等级是10。前后两次select得到的是一样的,这就是可重复读
的含义。
通过分析MVCC详解部分,可以得出,基于MVCC,在RR隔离级别下,很好解决了幻读
问题,但是我们知道,select for update
是产生当前读,不再是快照读,那么此种情况,MySQL又是怎么解决幻读
问题的呢?基于时间问题(整理画图的确需要花比较多的时间),此处先给结论,后面再分析在当前读的情况下,MySQL是怎么解决幻读
READ COMMITTED
—— Générez un ReadView
à chaque fois avant de lire les données REPEATABLE READ
—— Lors de la première lecture des données, générez un ReadViewNuméro d'heure | trx 100 | trx 200 | |
---|---|---|---|
① td> | COMMENCER ; | ||
② |
|
BEGIN; | BEGIN; |
③ |
> |
mettre à jour la note définie par la personne =20 où l'identifiant =1 ; | |
④ | > |
mettre à jour le grade de la personne =40 où id =1 ; | |
⑤ td> | SELECT * FROM personne WHERE id = 1; | ||
⑥ | COMMIT ; | ||
⑦ | mettre à jour la personne définie la note =70 où id =1 ; | ||
⑧ | SELECT * FROM personne WHERE id = 1 ; | ||
⑨ | COMMIT; | ||
? | COMMIT ; |
trx 100
exécutant la soumission de la transaction, la chaîne de versions enregistrée dans la ligne id=1 est la suivante :
🎜🎜Au moment ⑤, lorsque la transaction trx 100
exécute l'instruction select
, elle générera d'abord un ReadView
, Le contenu de la liste <code>m_ids
de ReadView est [100, 200]
, min_trx_id
est 100
, max_trx_id
est 201
et creator_trx_id
est 0
. À ce stade, sélectionnez le visible. enregistrement de la chaîne de versions. La chaîne de versions commence du haut Traverse au suivant : Parce que grade=40, la valeur de trx_id
est 100
, qui est dans . m_ids
, donc l'enregistrement est invisible. De même, grade= Ceux de moins de 20 ans sont également manquants. Continuez à descendre, grade = 20, la valeur trx_id
est 80
, ce qui est inférieur à la valeur min_trx_id
ReadView code>100, cette version répond donc aux exigences et les enregistrements de niveau 10 sont renvoyés à l'utilisateur. 🎜🎜Au moment ⑧, si le niveau d'isolement de la transaction est READ COMMITTED
, un ReadView
distinct sera généré, et le de ce <code>ReadView Le contenu de la liste m_ids
est [200]
, min_trx_id
est 200
et max_trx_id code> est <code> 201
, creator_trx_id
est 0
À ce stade, sélectionnez l'enregistrement visible dans la chaîne de versions et parcourez la chaîne de versions depuis le haut. vers le bas : parce que grade=70, la valeur de trx_id
est 200
, qui est en m_ids
, donc l'enregistrement n'est pas visible. Continuez à parcourir vers le bas, grade=40,trx_id
>La valeur est 100
, ce qui est inférieur à la valeur min_trx_id
200
dans ReadView
, pour que cette version réponde aux exigences, renvoie Ce qui est donné à l'utilisateur est un enregistrement de niveau 40. 🎜🎜Au temps ⑧, si le niveau d'isolement de la transaction est REPEATABLE READ
, au temps ⑧, un ReadView
séparé ne sera pas généré, mais le ReadView
, donc le niveau renvoyé à l'utilisateur est 10. Le résultat des deux sélections est le même. C'est le sens de la lecture répétable
. 🎜 phantom est bien résolu le problème de lecture
, mais nous savons que select for update
génère la lecture actuelle et n'est plus une lecture instantanée. Dans ce cas, comment MySQL résout-il phantom read<.> >Qu'en est-il du problème ? En fonction du problème de temps (il faut beaucoup de temps pour trier le dessin), je vais d'abord donner la conclusion ici, puis analyser comment MySQL résout le problème de <code>lecture fantôme
dans la situation de lecture actuelle. : 🎜🎜🎜🎜 Lecture actuelle🎜 : utilisez le verrouillage à clé suivante (verrouillage d'espacement) pour verrouiller afin de garantir que les lectures fantômes ne se produisent pas🎜🎜🎜Quant à la façon dont le verrouillage d'espacement résout le problème de lecture fantôme dans la situation de lecture actuelle, les amis intéressés peuvent ajoutez un suivi J'aime🎜🎜[Recommandations associées : 🎜Tutoriel vidéo MySQL🎜]🎜
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!