Apakah transaksi dalam mysql

Dalam MySQL, transaksi ialah mekanisme, urutan operasi dan unit pelaksanaan program untuk mengakses dan mengemas kini pangkalan data. Satu urus niaga mengandungi satu atau lebih perintah operasi pangkalan data, dan semua perintah akan diserahkan atau dibatalkan kepada sistem secara keseluruhannya, iaitu set perintah pangkalan data ini sama ada akan dilaksanakan atau tiada satu pun daripadanya akan dilaksanakan.

Persekitaran pengendalian tutorial ini: sistem windows7, versi mysql5.6, komputer Dell G3.

Transaksi pangkalan data ialah mekanisme, urutan operasi, unit pelaksanaan program untuk mengakses dan mengemas kini pangkalan data, dan termasuk satu set perintah operasi pangkalan data.

Transaksi menyerahkan atau membatalkan permintaan operasi kepada sistem bersama-sama dengan semua arahan secara keseluruhan, iaitu set perintah pangkalan data ini sama ada semua dilaksanakan atau tiada yang dilaksanakan, jadi transaksi itu adalah unit logik yang tidak boleh dibahagikan kerja.

Apabila melakukan operasi serentak pada sistem pangkalan data, urus niaga digunakan sebagai unit kawalan terkecil, yang amat sesuai untuk sistem pangkalan data yang dikendalikan oleh berbilang pengguna pada masa yang sama.

Sebagai pangkalan data hubungan, MySQL menyokong transaksi.

Semak dahulu asas transaksi MySQL.

1. Seni bina logik dan enjin storan

Sumber imej: https://blog.csdn .net/fuzhongmin05/article/details/70904190

Seperti yang ditunjukkan dalam rajah di atas, seni bina logik pelayan MySQL boleh dibahagikan kepada tiga lapisan dari atas ke bawah:

(1) Yang pertama lapisan: memproses sambungan terminal pelanggan, pengesahan kebenaran, dsb.

(2) Lapisan kedua: lapisan pelayan, bertanggungjawab untuk penghuraian, pengoptimuman, caching pernyataan pertanyaan, pelaksanaan fungsi terbina dalam, prosedur tersimpan, dsb.

(3) Lapisan ketiga: enjin storan, bertanggungjawab untuk penyimpanan dan mendapatkan semula data dalam MySQL. Lapisan pelayan dalam MySQL tidak mengurus transaksi dan transaksi dilaksanakan oleh enjin storan. Enjin storan MySQL yang menyokong transaksi termasuk InnoDB, Kluster NDB, dsb., antaranya InnoDB adalah enjin storan lain yang paling banyak digunakan tidak menyokong transaksi, seperti MyIsam, Memory, dsb.

Melainkan dinyatakan sebaliknya, kandungan yang diterangkan dalam artikel berikut adalah berdasarkan InnoDB.

2 Komit dan tarik balik

Transaksi MySQL biasa beroperasi seperti berikut:

start transaction;
……  #一条或多条sql语句
commit;

di mana mula transaksi mengenal pasti permulaan urus niaga, komit melakukan transaksi, dan menulis keputusan pelaksanaan ke pangkalan data. Jika terdapat masalah dengan pelaksanaan pernyataan SQL, rollback akan dipanggil untuk melancarkan semula semua pernyataan SQL yang telah berjaya dilaksanakan. Sudah tentu, anda juga boleh menggunakan penyata rollback secara langsung dalam transaksi untuk melancarkan semula.

Autokomit

MySQL menggunakan mod autokomit secara lalai, seperti ditunjukkan di bawah:

Dalam mod autokomit , jika transaksi tidak dimulakan secara eksplisit dengan memulakan transaksi, maka setiap pernyataan SQL akan dianggap sebagai transaksi untuk melaksanakan operasi komit.

Autokomit boleh dimatikan dengan cara berikut; perlu diingat bahawa parameter autokomit adalah khusus untuk sambungan Mengubah suai parameter dalam satu sambungan tidak akan menjejaskan sambungan lain.

Jika autocommit dimatikan, semua penyata sql berada dalam satu transaksi sehingga komit atau rollback dilaksanakan, transaksi tamat dan transaksi lain bermula.

Operasi khas

Dalam MySQL, terdapat beberapa arahan khas Jika arahan ini dilaksanakan dalam transaksi, commit akan dipaksa untuk melakukan transaksi dengan segera; Penyata DDL (buat jadual/jatuhkan jadual/ubah/jadual), penyata jadual kunci, dsb.

Walau bagaimanapun, arahan pilih, masukkan, kemas kini dan padam yang biasa digunakan tidak akan memaksa transaksi dilakukan.

3. Ciri-ciri ACID

ACID ialah ukuran empat ciri urus niaga:

• Atomicity , atau tidak boleh dibahagikan)
• Ketekalan (Ketekalan)
• Pengasingan (Pengasingan)
• Ketahanan (Ketahanan)

Ikuti Mengikut piawaian yang ketat, hanya transaksi yang memenuhi ciri-ciri ACID pada masa yang sama dianggap sebagai urus niaga, bagaimanapun, dalam pelaksanaan vendor pangkalan data utama, terdapat sangat sedikit transaksi yang benar-benar memenuhi ACID. Sebagai contoh, urus niaga Kluster NDB MySQL tidak memenuhi ketahanan dan tahap pengasingan lalai InnoDB boleh dibaca berulang, yang tidak memenuhi pengasingan tahap pengasingan lalai Oracle ialah READ COMMITTED, yang tidak memenuhi pengasingan... Oleh itu; , dengan Dikatakan bahawa ACID adalah syarat yang mesti dipenuhi oleh urus niaga, Sebaliknya, adalah lebih baik untuk mengatakan bahawa ia adalah empat dimensi untuk mengukur transaksi.

Ciri-ciri ACID dan prinsip pelaksanaannya akan diperkenalkan secara terperinci di bawah untuk memudahkan pemahaman, susunan pengenalan bukan A-C-I-D sahaja.

Atomicity

1. Definisi

Atomicity bermaksud bahawa urus niaga ialah unit kerja yang tidak boleh dibahagikan, di mana operasi sama ada dilakukan atau tiada; jika pernyataan SQL dalam urus niaga gagal dilaksanakan, pernyataan yang dilaksanakan juga mesti digulung semula dan pangkalan data kembali ke nyatakan sebelum transaksi.

2. Prinsip pelaksanaan: batal log

Sebelum menerangkan prinsip atomicity, perkenalkan dahulu log transaksi MySQL. Terdapat banyak jenis log MySQL, seperti log binari, log ralat, log pertanyaan, log pertanyaan perlahan, dan lain-lain. Selain itu, enjin storan InnoDB juga menyediakan dua jenis log urus niaga: log buat semula (log semula) dan buat asal log ( log putar balik). Log buat semula digunakan untuk memastikan ketahanan transaksi; log buat asal adalah asas untuk keatomisan transaksi dan pengasingan.

Mari bincang tentang buat asal log. Kunci untuk mencapai atomicity adalah untuk dapat membuat asal semua pernyataan SQL yang berjaya dilaksanakan apabila transaksi ditarik balik. InnoDB melaksanakan pemulangan semula dengan bergantung pada log buat asal: Apabila transaksi mengubah suai pangkalan data, InnoDB akan menjana log buat asal yang sepadan ; Jika pelaksanaan urus niaga gagal atau tarik balik dipanggil, menyebabkan urus niaga ditarik balik, anda boleh menggunakan maklumat dalam log batal untuk melancarkan semula data seperti sebelumnya pengubahsuaian.

log asal ialah log logik, yang merekodkan maklumat yang berkaitan dengan pelaksanaan SQL. Apabila rollback berlaku, InnoDB akan melakukan perkara yang bertentangan dengan kerja sebelumnya berdasarkan kandungan log buat asal: untuk setiap sisipan, pemadaman akan dilaksanakan semasa rollback, sisipan akan dilaksanakan semasa rollback; , pemadaman akan dilaksanakan semasa rollback Apabila melancarkan, kemas kini terbalik akan dilakukan untuk menukar kembali data.

Ambil operasi kemas kini sebagai contoh: apabila transaksi melaksanakan kemas kini, log buat asal yang dijana akan mengandungi kunci utama bagi baris yang diubah suai (untuk mengetahui baris mana yang telah diubah suai), lajur mana yang telah diubah suai, dan nilai lajur ini sebelum dan selepas pengubahsuaian Nilai dan maklumat lain, anda boleh menggunakan maklumat ini untuk memulihkan data kepada keadaan sebelum kemas kini apabila melancarkan semula.

Kegigihan

1 Definisi

Kegigihan bermaksud sebaik sahaja transaksi dilakukan, perubahannya kepada pangkalan data haruslah. adalah kekal. Operasi atau kegagalan seterusnya tidak sepatutnya mempunyai sebarang kesan ke atasnya.

2. Prinsip pelaksanaan: buat semula log

Kedua-dua log buat semula dan buat asal tergolong dalam log transaksi InnoDB. Mari kita bercakap tentang latar belakang kewujudan redo log.

InnoDB ialah enjin storan MySQL, dan data disimpan pada cakera Walau bagaimanapun, jika cakera IO diperlukan setiap kali untuk membaca dan menulis data, kecekapan akan menjadi sangat rendah. Untuk tujuan ini, InnoDB menyediakan cache (Kolam Penampan mengandungi pemetaan beberapa halaman data pada cakera dan berfungsi sebagai penimbal untuk mengakses pangkalan data: apabila membaca data daripada pangkalan data, ia akan dibaca terlebih dahulu daripada pangkalan data). Buffer Pool Jika ia tidak wujud dalam Pool, ia akan dibaca dari cakera dan dimasukkan ke dalam Buffer Pool apabila menulis data ke pangkalan data, ia akan ditulis ke Buffer Pool terlebih dahulu, dan diubah suai data dalam Kolam Penampan akan sentiasa dimuat semula ke cakera (proses ini dipanggil dirty flushing ).

Penggunaan Buffer Pool sangat meningkatkan kecekapan membaca dan menulis data, tetapi ia juga membawa masalah baharu: jika MySQL tidak berfungsi dan data yang diubah suai dalam Buffer Pool tidak dibuang ke cakera, ia akan menyebabkan Kehilangan data dan ketahanan transaksi tidak dapat dijamin.

Jadi, buat semula log diperkenalkan untuk menyelesaikan masalah ini: apabila data diubah suai, selain mengubah suai data dalam Buffer Pool, operasi juga akan direkodkan dalam log buat semula apabila transaksi dilakukan , antara muka fsync akan dipanggil untuk Buat semula log digunakan untuk mengepam cakera. Jika MySQL rosak, anda boleh membaca data dalam log buat semula dan memulihkan pangkalan data apabila ia dimulakan semula. Log buat semula menggunakan WAL (Pengelogan tulis ke hadapan, log tulis ke hadapan terlebih dahulu ditulis pada log dan kemudian dikemas kini ke Kolam Penampan, memastikan data tidak akan hilang akibat masa henti MySQL, sekali gus memenuhi ketahanan). keperluan.

Memandangkan log buat semula juga perlu menulis log ke cakera apabila urus niaga dilakukan, mengapakah ia lebih pantas daripada terus menulis data yang diubah suai dalam Kolam Penampan ke cakera (iaitu, membersihkannya dengan kotor)? Terdapat dua sebab utama:

(1) Pembersihan kotor ialah IO rawak, kerana lokasi data yang diubah suai setiap kali adalah rawak, tetapi menulis log buat semula ialah operasi tambah dan tergolong dalam IO berjujukan.

(2) Pembersihan kotor adalah berdasarkan halaman data (Halaman) Saiz halaman lalai MySQL ialah 16KB Pengubahsuaian kecil pada Halaman memerlukan keseluruhan halaman ditulis dan log buat semula keperluan sebenar Dalam bahagian penulisan, IO yang tidak sah dikurangkan dengan banyaknya.

3. buat semula log dan binlog

Kami tahu bahawa terdapat juga binlog (log binari) dalam MySQL yang juga boleh merekodkan operasi tulis dan digunakan untuk pemulihan Data, tetapi kedua-duanya pada asasnya berbeza:

(1) Fungsi yang berbeza: buat semula log digunakan untuk pemulihan ranap untuk memastikan masa henti MySQL tidak akan menjejaskan ketahanan binlog digunakan untuk Titik pemulihan ranap -pemulihan dalam masa memastikan pelayan boleh memulihkan data berdasarkan titik masa Selain itu, binlog juga digunakan untuk replikasi tuan-hamba.

(2) Tahap berbeza: log buat semula dilaksanakan oleh enjin storan InnoDB, manakala binlog dilaksanakan oleh lapisan pelayan MySQL (sila rujuk pengenalan kepada seni bina logik MySQL sebelum ini dalam artikel), dan menyokong kedua-dua InnoDB dan enjin storan lain.

（3）内容不同：redo log是物理日志，内容基于磁盘的Page；binlog的内容是二进制的，根据binlog_format参数的不同，可能基于sql语句、基于数据本身或者二者的混合。

（4）写入时机不同：binlog在事务提交时写入；redo log的写入时机相对多元：

• 前面曾提到：当事务提交时会调用fsync对redo log进行刷盘；这是默认情况下的策略，修改innodb_flush_log_at_trx_commit参数可以改变该策略，但事务的持久性将无法保证。
• 除了事务提交时，还有其他刷盘时机：如master thread每秒刷盘一次redo log等，这样的好处是不一定要等到commit时刷盘，commit速度大大加快。

四、隔离性

1. 定义

与原子性、持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的相互影响。隔离性是指，事务内部的操作与其他事务是隔离的，并发执行的各个事务之间不能互相干扰。严格的隔离性，对应了事务隔离级别中的Serializable (可串行化)，但实际应用中出于性能方面的考虑很少会使用可串行化。

隔离性追求的是并发情形下事务之间互不干扰。简单起见，我们主要考虑最简单的读操作和写操作(加锁读等特殊读操作会特殊说明)，那么隔离性的探讨，主要可以分为两个方面：

• (一个事务)写操作对(另一个事务)写操作的影响：锁机制保证隔离性
• (一个事务)写操作对(另一个事务)读操作的影响：MVCC保证隔离性

2. 锁机制

首先来看两个事务的写操作之间的相互影响。隔离性要求同一时刻只能有一个事务对数据进行写操作，InnoDB通过锁机制来保证这一点。

锁机制的基本原理可以概括为：事务在修改数据之前，需要先获得相应的锁；获得锁之后，事务便可以修改数据；该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁。

行锁与表锁

按照粒度，锁可以分为表锁、行锁以及其他位于二者之间的锁。表锁在操作数据时会锁定整张表，并发性能较差；行锁则只锁定需要操作的数据，并发性能好。但是由于加锁本身需要消耗资源(获得锁、检查锁、释放锁等都需要消耗资源)，因此在锁定数据较多情况下使用表锁可以节省大量资源。MySQL中不同的存储引擎支持的锁是不一样的，例如MyIsam只支持表锁，而InnoDB同时支持表锁和行锁，且出于性能考虑，绝大多数情况下使用的都是行锁。

如何查看锁信息

有多种方法可以查看InnoDB中锁的情况，例如：

select * from information_schema.innodb_locks; #锁的概况
show engine innodb status; #InnoDB整体状态，其中包括锁的情况

下面来看一个例子：

#在事务A中执行：
start transaction;
update account SET balance = 1000 where id = 1;
#在事务B中执行：
start transaction;
update account SET balance = 2000 where id = 1;

此时查看锁的情况：

show engine innodb status查看锁相关的部分：

通过上述命令可以查看事务24052和24053占用锁的情况；其中lock_type为RECORD，代表锁为行锁(记录锁)；lock_mode为X，代表排它锁(写锁)。

除了排它锁(写锁)之外，MySQL中还有共享锁(读锁)的概念。由于本文重点是MySQL事务的实现原理，因此对锁的介绍到此为止，后续会专门写文章分析MySQL中不同锁的区别、使用场景等，欢迎关注。

介绍完写操作之间的相互影响，下面讨论写操作对读操作的影响。

3. 脏读、不可重复读和幻读

首先来看并发情况下，读操作可能存在的三类问题：

（1）脏读：当前事务(A)中可以读到其他事务(B)未提交的数据（脏数据），这种现象是脏读。举例如下（以账户余额表为例）：

（2）不可重复读：在事务A中先后两次读取同一个数据，两次读取的结果不一样，这种现象称为不可重复读。脏读与不可重复读的区别在于：前者读到的是其他事务未提交的数据，后者读到的是其他事务已提交的数据。举例如下：

(3) Bacaan hantu: Dalam transaksi A, pangkalan data disoal dua kali mengikut keadaan tertentu, dan bilangan hasil dua pertanyaan adalah berbeza Fenomena ini dipanggil bacaan hantu. Perbezaan antara bacaan tidak berulang dan bacaan hantu boleh difahami dengan mudah sebagai: yang pertama bermakna data telah berubah, manakala yang kedua bermakna bilangan baris data telah berubah. Contohnya:

4 Tahap pengasingan transaksi

Terdapat empat tahap pengasingan ditakrifkan dalam SQL. standard , dan menetapkan sama ada masalah di atas wujud di bawah setiap tahap pengasingan. Secara umumnya, lebih rendah tahap pengasingan, lebih rendah overhed sistem, lebih tinggi konkurensi yang boleh disokong, tetapi lebih teruk pengasingan. Hubungan antara tahap pengasingan dan masalah bacaan adalah seperti berikut:

Dalam aplikasi sebenar, baca tanpa komitmen akan menyebabkan banyak masalah semasa bersamaan, dan prestasi secara relatifnya Peningkatan tahap pengasingan lain adalah terhad dan oleh itu kurang digunakan. Boleh BersiriMemaksa urus niaga untuk bersiri, kecekapan serentak adalah sangat rendah. Ia hanya boleh digunakan apabila keperluan ketekalan data sangat tinggi dan tiada keselarasan boleh diterima, jadi ia jarang digunakan. Oleh itu, dalam kebanyakan sistem pangkalan data, tahap pengasingan lalai ialah Baca Komitmen ( seperti Oracle) atau Bacaan Boleh Ulang (selepas ini dirujuk sebagai RR).

Anda boleh melihat tahap pengasingan global dan tahap pengasingan sesi ini melalui dua arahan berikut:

InnoDB Tahap pengasingan lalai ialah RR, dan kami akan menumpukan pada RR kemudian. Perlu diingatkan bahawa dalam standard SQL, RR tidak dapat mengelakkan masalah bacaan hantu, tetapi RR yang dilaksanakan oleh InnoDB mengelakkan masalah bacaan hantu.

5. MVCC

RR menyelesaikan masalah seperti bacaan kotor, bacaan tidak boleh berulang, bacaan hantu, dll. Ia menggunakan MVCC: the nama penuh MVCC ialah Multi- Version Concurrency Control, protokol kawalan concurrency berbilang versi. Contoh berikut menggambarkan dengan baik ciri MVCC: pada masa yang sama, data yang dibaca oleh transaksi yang berbeza mungkin berbeza (iaitu, berbilang versi) - pada masa T5, transaksi A dan transaksi C boleh membaca versi yang berbeza.

Kelebihan terbesar MVCC ialah membaca tidak dikunci, jadi tiada konflik antara membaca dan menulis, dan prestasi serentak adalah baik. InnoDB melaksanakan MVCC, dan berbilang versi data boleh wujud bersama ia terutamanya berdasarkan teknologi dan struktur data berikut:

1) Lajur tersembunyi: Setiap baris data dalam InnoDB mempunyai lajur tersembunyi dan lajur tersembunyi mengandungi. data baris ini id Transaksi, penunjuk untuk membuat asal log, dsb.

2) Rantaian versi berdasarkan log buat asal: Seperti yang dinyatakan sebelum ini, lajur tersembunyi bagi setiap baris data mengandungi penuding kepada log buat asal dan setiap log buat asal juga akan menunjukkan kepada versi log buat asal yang lebih awal. , dengan itu membentuk rantaian versi A.

3) ReadView: Dengan menyembunyikan lajur dan rantaian versi, MySQL boleh memulihkan data kepada versi yang ditentukan tetapi versi yang hendak dipulihkan perlu ditentukan berdasarkan ReadView. Apa yang dipanggil ReadView bermaksud bahawa transaksi (dirakam sebagai transaksi A) mengambil gambar keseluruhan sistem transaksi (trx_sys) pada masa tertentu Apabila operasi baca dilakukan kemudian, ID transaksi dalam data baca akan dibandingkan dengan petikan trx_sys, dengan itu Tentukan sama ada data itu boleh dilihat oleh ReadView, iaitu, sama ada ia boleh dilihat oleh transaksi A.

Kandungan utama dalam trx_sys dan kaedah menilai keterlihatan adalah seperti berikut:

• low_limit_id: Menunjukkan id yang harus diberikan kepada transaksi seterusnya dalam sistem apabila menjana ReadView. Jika ID transaksi data lebih besar daripada atau sama dengan low_limit_id, ia tidak akan kelihatan kepada ReadView.
• up_limit_id: Menunjukkan ID transaksi terkecil antara transaksi baca dan tulis aktif dalam sistem semasa apabila ReadView dijana. Jika id transaksi data kurang daripada up_limit_id, ia kelihatan kepada ReadView.
• rw_trx_ids: Mewakili senarai ID transaksi bagi transaksi baca dan tulis aktif dalam sistem semasa apabila ReadView dijana. Jika id transaksi data adalah antara low_limit_id dan up_limit_id, anda perlu menentukan sama ada id urus niaga berada dalam rw_trx_ids: jika ya, ini bermakna transaksi masih aktif apabila ReadView dijana, jadi data tidak kelihatan kepada ReadView jika tidak, ini bermakna transaksi adalah apabila ReadView telah diserahkan, jadi data kelihatan kepada ReadView.

Yang berikut mengambil tahap pengasingan RR sebagai contoh dan menerangkannya bersama-sama dengan isu yang dinyatakan di atas.

(1) Bacaan kotor

当事务A在T3时刻读取zhangsan的余额前，会生成ReadView，由于此时事务B没有提交仍然活跃，因此其事务id一定在ReadView的rw_trx_ids中，因此根据前面介绍的规则，事务B的修改对ReadView不可见。接下来，事务A根据指针指向的undo log查询上一版本的数据，得到zhangsan的余额为100。这样事务A就避免了脏读。

（2）不可重复读

当事务A在T2时刻读取zhangsan的余额前，会生成ReadView。此时事务B分两种情况讨论，一种是如图中所示，事务已经开始但没有提交，此时其事务id在ReadView的rw_trx_ids中；一种是事务B还没有开始，此时其事务id大于等于ReadView的low_limit_id。无论是哪种情况，根据前面介绍的规则，事务B的修改对ReadView都不可见。

当事务A在T5时刻再次读取zhangsan的余额时，会根据T2时刻生成的ReadView对数据的可见性进行判断，从而判断出事务B的修改不可见；因此事务A根据指针指向的undo log查询上一版本的数据，得到zhangsan的余额为100，从而避免了不可重复读。

（3）幻读

MVCC避免幻读的机制与避免不可重复读非常类似。

当事务A在T2时刻读取0

当事务A在T5时刻再次读取0

扩展

前面介绍的MVCC，是RR隔离级别下“非加锁读”实现隔离性的方式。下面是一些简单的扩展。

（1）读已提交（RC）隔离级别下的非加锁读

RC与RR一样，都使用了MVCC，其主要区别在于：

RR是在事务开始后第一次执行select前创建ReadView，直到事务提交都不会再创建。根据前面的介绍，RR可以避免脏读、不可重复读和幻读。

RC每次执行select前都会重新建立一个新的ReadView，因此如果事务A第一次select之后，事务B对数据进行了修改并提交，那么事务A第二次select时会重新建立新的ReadView，因此事务B的修改对事务A是可见的。因此RC隔离级别可以避免脏读，但是无法避免不可重复读和幻读。

（2）加锁读与next-key lock

按照是否加锁，MySQL的读可以分为两种：

一种是非加锁读，也称作快照读、一致性读，使用普通的select语句，这种情况下使用MVCC避免了脏读、不可重复读、幻读，保证了隔离性。

另一种是加锁读，查询语句有所不同，如下所示：

#共享锁读取
select...lock in share mode
#排它锁读取
select...for update

加锁读在查询时会对查询的数据加锁（共享锁或排它锁）。由于锁的特性，当某事务对数据进行加锁读后，其他事务无法对数据进行写操作，因此可以避免脏读和不可重复读。而避免幻读，则需要通过next-key lock。next-key lock是行锁的一种，实现相当于record lock(记录锁) + gap lock(间隙锁)；其特点是不仅会锁住记录本身(record lock的功能)，还会锁定一个范围(gap lock的功能)。因此，加锁读同样可以避免脏读、不可重复读和幻读，保证隔离性。

6. 总结

Ringkasnya, RR yang dilaksanakan oleh InnoDB mencapai tahap pengasingan tertentu melalui mekanisme kunci (termasuk kunci kekunci seterusnya), MVCC (termasuk lajur tersembunyi data, rantai versi berdasarkan log asal, ReadView), dll. Boleh memenuhi keperluan kebanyakan senario.

Walau bagaimanapun, perlu diingat bahawa walaupun RR mengelakkan masalah bacaan hantu, ia tidak boleh disiri dan tidak dapat menjamin pengasingan sepenuhnya:

Contoh pertama, jika The Bacaan pertama dalam transaksi menggunakan bacaan tidak berkunci, dan bacaan kedua menggunakan bacaan berkunci Jika data berubah antara kedua-dua bacaan, keputusan kedua-dua bacaan adalah berbeza kerana kunci tidak akan digunakan.

Contoh kedua adalah seperti yang ditunjukkan di bawah. Anda boleh mengesahkannya sendiri.

Konsistensi

1. pelaksanaan, kekangan integriti pangkalan data belum dimusnahkan, dan keadaan data sebelum dan selepas transaksi dilaksanakan adalah sah. Kekangan integriti pangkalan data termasuk tetapi tidak terhad kepada: integriti entiti (seperti kunci utama baris wujud dan unik), integriti lajur (seperti jenis, saiz dan panjang medan mesti memenuhi keperluan), kekangan kunci asing dan Kesempurnaan yang ditentukan pengguna (contohnya, jumlah baki kedua-dua akaun harus kekal tidak berubah sebelum dan selepas pemindahan).

2. Pelaksanaan

Boleh dikatakan bahawa konsistensi adalah matlamat utama yang diusahakan oleh urus niaga: atomicity, ketahanan dan pengasingan yang disebut sebelum ini. , semuanya untuk memastikan ketekalan keadaan pangkalan data. Selain itu, selain jaminan di peringkat pangkalan data, pelaksanaan ketekalan juga memerlukan jaminan di peringkat aplikasi. Langkah-langkah untuk mencapai konsistensi termasuk:

Pastikan atomicity, ketahanan dan pengasingan Jika ciri-ciri ini tidak dapat dijamin, konsistensi transaksi tidak boleh dijamin sama ada

Pangkalan data itu sendiri. memberikan jaminan, contohnya, tidak dibenarkan memasukkan nilai rentetan ke dalam lajur integer, panjang rentetan tidak boleh melebihi had lajur, dsb.

• Jaminan disediakan pada peringkat aplikasi, contohnya, jika operasi pemindahan hanya memotong baki pemindah, tetapi tidak Meningkatkan baki penerima, tidak kira betapa sempurnanya pangkalan data dilaksanakan, keadaan tidak boleh dijamin konsisten
• Ringkasan
• Berikut meringkaskan ciri ACID dan prinsip pelaksanaannya:

Atomicity: Penyata sama ada dilaksanakan sepenuhnya atau tidak dilaksanakan sama sekali Ini adalah ciri teras transaksi itu sendiri ditakrifkan oleh atomicity. pelaksanaan terutamanya berdasarkan log batal

Kegigihan: transaksi terjamin Selepas penyerahan, data tidak akan hilang disebabkan masa henti dan sebab-sebab lain, pelaksanaan terutamanya berdasarkan log buat semula

• pengasingan: memastikan bahawa pelaksanaan urus niaga tidak terjejas oleh urus niaga lain sebanyak mungkin tahap pengasingan lalai InnoDB ialah RR, dan pelaksanaan RR terutamanya Berdasarkan mekanisme kunci (termasuk kunci kekunci seterusnya), MVCC (termasuk lajur tersembunyi data, rantai versi; berdasarkan log asal, ReadView)
• Ketekalan: matlamat utama yang diusahakan oleh transaksi, realisasi ketekalan memerlukan kedua-dua pangkalan data Perlindungan di peringkat aplikasi juga memerlukan perlindungan di peringkat aplikasi

Atas ialah kandungan terperinci Apakah transaksi dalam mysql. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!