Dieser Artikel vermittelt Ihnen relevantes Wissen über MySQL, das hauptsächlich die Verwendung von MySQL-Transaktionen und die Risiken langer Transaktionen, MySQL-Transaktionen und ihre Eigenschaften, durch gleichzeitige Transaktionen verursachte Probleme sowie Transaktionsisolationsstufen und -demonstrationen sowie einzelne Versionskontrollsperren vorstellt und Mehrversions-Parallelitätskontrolle MVCC usw. Schauen wir sie uns gemeinsam an. Ich hoffe, dass es für alle hilfreich ist.
Empfohlenes Lernen: MySQL-Video-Tutorial
Eine Transaktion ist eine Reihe von Vorgängen, die als eine einzige logische Arbeitseinheit ausgeführt werden. Entweder sind alle oder keine dieser Vorgänge eine integrale Arbeitseinheit.
Während des Bezahlvorgangs werden beispielsweise eine Reihe von Vorgängen durchgeführt, z. B. das Überprüfen des Kontostands, das Addieren oder Subtrahieren und das Aktualisieren des Kontostands. Diese Vorgänge müssen gleichzeitig erfolgen. Andernfalls wird angezeigt, dass Ihre Zahlung erfolgreich war, das System jedoch das Geld nicht erhalten hat. Die MyISAM-Engine unterstützt keine Transaktionen Eine Transaktion. Eine logische Arbeitseinheit muss vier Merkmale in einem relationalen Datenbankverwaltungssystem erfüllen.
Die sogenannte ACID: Atomizität, Konsistenz, Isolation und Haltbarkeit.
: Die Integritätsgrenzen der Datenbank werden vor und nach einer Transaktion nicht verletzt.
Isolation: Beziehungen werden angezeigt, wenn mehrere Transaktionen gleichzeitig auf dieselben Daten in der Datenbank zugreifen.
Persistenz: Nach Abschluss der Transaktion bleiben die durch die Transaktion vorgenommenen Änderungen bestehen und gehen nicht verloren.
ACID muss durch Redo- und Undo-Protokolle garantiert werden. Detaillierte Erläuterung des MySQL-Protokollsystems: (wird später ergänzt)
3. MySQL-TransaktionsverwendungMySQL verfügt über die folgenden zwei Transaktionsstartmethoden:
3.1. Explizite StarttransaktionsanweisungenBEGIN -- 开启事务 START TRANSACTION -- 开启事务 INSERT INTO fork_business_detail VALUES ( 4, '123', '123', '123004', '2022-11-12 17:17:29', '1', '2022-11-12 17:17:37', '1' ); COMMIT -- 提交事务 ROLLBACK -- 回滚事务
set autocommit=0 -- 关闭自动提交 INSERT INTO fork_business_detail VALUES ( 4, '123', '123', '123004', '2022-11-12 17:17:29', '1', '2022-11-12 17:17:37', '1' ); COMMIT -- 提交事务 ROLLBACK -- 回滚事务
Je höher der Isolationsgrad, desto geringer die Effizienz. Oft müssen wir ein Gleichgewicht zwischen beiden finden. Zu den Isolationsstufen für SQL-Standardtransaktionen gehören: Lesen (Lesen), nicht festgeschrieben (Lesen nicht festgeschrieben), Lesen (Lesen), festgeschrieben (Lesen festgeschrieben), wiederholbares Lesen (wiederholbares Lesen) und serialisierbar (serialisierbar).
, Read Uncommitted), das den Zwischenprozess der Transaktion lesen kann. Es verstößt gegen ACID-Eigenschaften und weist Dirty-Read-Probleme auf. Daher wird es grundsätzlich nicht verwendet und kann ignoriert werden.
Read Committed(RC, Read Committed), was bedeutet, dass wir sehen können, dass dies auch die am häufigsten verwendete Ebene ist, wenn andere Transaktionen festgeschrieben wurden. Aus einigen historischen Gründen wird RC jedoch möglicherweise nicht häufig in Produktionsumgebungen verwendet.
Repeatable Read(RR, Repeatable Read) ist derzeit das am weitesten verbreitete Level. Es verfügt über eine Lückenverriegelung, die immer noch die Standardstufe ist. Auf dieser Ebene treten häufig Deadlocks, geringe Parallelität und andere Probleme auf.
Serializable(serialisierbar) ist keine Implementierung mit mehreren Versionen, sondern eine Implementierung mit einer Version, da alle Implementierungen über Sperren implementiert werden. Wird grundsätzlich nicht verwendet und kann ignoriert werden. 2. Durch gleichzeitige Transaktionen verursachte Probleme Nicht wiederholbares Lesen: Transaktion A liest dieselben Daten mehrmals. Transaktion B aktualisiert und schreibt Daten während mehrerer Lesevorgänge von Transaktion A fest, was zu inkonsistenten Ergebnissen führt, wenn Transaktion A dieselben Daten mehrmals erfasst.
Eine Transaktion liest Daten, die von einer anderen Transaktion übermittelt wurden, was dazu führt, dass unterschiedliche Daten zweimal gelesen werden 幻读:A查出来数据,此时B提交,A再次查同一数据时结果不一致。一个事务前后两次读取的数据不一致,是因为其他事务插入数据导致的事务并发情况 不可重复读和幻读很容易混淆,不可重复读侧重于修改,而幻读侧重于添加或删除。要解决不可重复读取的问题,只需要锁,符合条件的行,而要解决幻读问题需要锁表。 将事务隔离级别修改为读未提交,可以看到,事务还没有提交,这时候去查询这条数据,发现数据已经可见了。 一个事务读取到其他事务已提交的数据导致前后两次读取数据不一样的情况。 serializable ,使用锁独占方式来确保只有一个版本时事务被隔离,因此锁可以理解为单版本控制。 在MySQL事务中,锁的实现与隔离级别有关。在RR(Repeatable Read)隔离级别下,MySQL使用间隙锁来防止以并行性为代价写入数据,以解决虚拟读取的问题。 这种类型的锁通常会导致死锁,因为它没有足够的并行性和许多冲突。现在流行的Row模式可以避免许多冲突甚至死锁,因此建议默认使用Row+RC(Read Committed)模式隔离级别,这可以大大提高数据库的读写并行性。 多版本控制,也称为MVCC,是指数据的多版本处理,以实现数据库中的高度并发数据访问,以及事务的可见性,以确保事务可以看到其应该看到的数据版本。 如何生成多个版本? 每次修改数据库时,撤消( Undo log)日志都会记录当前修改记录的事务号和修改前数据状态的存储地址(即ROLL_PTR),以便在必要时回滚旧数据版本。 例如,读取事务查询当前记录,但最近的事务尚未提交。根据原子性,读取事务无法看到最新的数据,但您可以在回滚段中找到旧版本数据,从而生成多个版本。 多版本控制巧妙地将独占和独占的稀有资源转换为并发,大大提高了数据库吞吐量和读/写性能。 推荐学习:mysql视频教程3、隔离级别问题剖析与演示
3.1 查看mysql事务隔离级别
SELECT @@transaction_isolation; -- 查看mysql事务隔离级别
SELECT @@tx_isolation; -- 查看mysql事务隔离级别
3.2、脏读问题
set session transaction isolation level read uncommitted; -- 设置成读未提交
SELECT @@tx_isolation; -- 查看mysql事务隔离级别
START TRANSACTION -- 事务A
INSERT INTO fork_business_detail VALUES ( 4, '123', '123', '123004', '2022-11-12 17:17:29', '1', '2022-11-12 17:17:37', '1' );
ROLLBACK
select * from fork_business_detail where id= 4 -- 事务B
3.3、不可重复读
select * from fork_business_detail where id= 4;
BEGIN; -- 开启事务
select * from fork_business_detail where id= 4;
UPDATE fork_business_detail set SUB_ODR_ID=123004 where id= 4;
COMMIT;
select * from fork_business_detail where id= 5;
三、MySQL事务实现原理
1、单版本控制——锁
2、多版本控制MVCC
Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des Transaktionsisolationsmechanismus und der Implementierungsprinzipien von MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!