Mari berbincang dengan anda tentang pengasingan transaksi dalam MySQL

Artikel ini akan membawa anda memahami pengasingan transaksi dalam MySQL, memperkenalkan ciri-ciri transaksi, tahap pengasingan, kaedah permulaan transaksi, dll. Saya harap ia akan membantu semua orang!

Transaksi adalah untuk memastikan satu set operasi pangkalan data sama ada semuanya berjaya atau semuanya gagal. Dalam MySQL, sokongan transaksi dilaksanakan pada lapisan enjin, tetapi tidak semua enjin menyokong transaksi. Sebagai contoh, enjin MyISAM asli MySQL tidak menyokong transaksi. [Cadangan berkaitan: tutorial mysql(video)]

1.Ciri-ciri transaksi

• Atomicity: semua transaksi dalam Operasi transaksi. sama ada siap sepenuhnya atau tidak siap sama sekali, dan tidak akan berakhir di tengah-tengah. Jika ralat berlaku semasa pelaksanaan urus niaga, ia akan digulung semula ke keadaan sebelum urus niaga dimulakan, seolah-olah urus niaga tidak pernah dilaksanakan
• Ketekalan: integriti pangkalan data sebelum urus niaga bermula dan selepas urus niaga tamat Tidak dimusnahkan
• Pengasingan: Pangkalan data membenarkan berbilang urus niaga serentak untuk membaca, menulis dan mengubah suai data pada masa yang sama Pengasingan boleh mengelakkan ketidakkonsistenan data akibat pelaksanaan silang apabila berbilang transaksi dilaksanakan secara serentak
.
• Kegigihan: Selepas urus niaga selesai, pengubahsuaian kepada data adalah kekal dan tidak akan hilang walaupun sistem gagal

2. Tahap pengasingan

1. Apabila berbilang transaksi dilaksanakan secara serentak pada pangkalan data, masalah seperti bacaan kotor, bacaan tidak berulang dan bacaan hantu mungkin berlaku

• Bacaan kotor: Transaksi B telah membaca transaksi A itu belum lagi dilakukan. Data
• Bacaan tidak boleh diulang: Satu transaksi membaca data kemas kini yang diserahkan dalam transaksi lain
• Baca hantu/baca maya: Satu transaksi membaca sisipan diserahkan dalam Data transaksi lain

2 Tahap pengasingan urus niaga termasuk: baca tidak komited, baca komited, baca berulang dan bersiri

• Baca tanpa komitmen: transaksi belum lagi Apabila melakukan, perubahan yang dibuatnya boleh dilihat oleh transaksi lain
• Komit baca: Selepas transaksi diserahkan, perubahan yang dibuatnya boleh dilihat oleh transaksi lain (untuk menyelesaikan bacaan kotor, tahap pengasingan lalai Oracle )
• Bacaan berulang : Data yang dilihat semasa pelaksanaan urus niaga sentiasa konsisten dengan data yang dilihat semasa urus niaga dimulakan, dan perubahan tanpa komitmen juga tidak dapat dilihat oleh transaksi lain (diselesaikan Bacaan kotor dan bacaan tidak boleh berulang, tahap pengasingan lalai MySQL)
• Pensirian: Untuk baris rekod yang sama, penulisan akan menambah kunci tulis, dan bacaan akan menambah kunci baca Apabila konflik kunci baca-tulis berlaku, transaksi yang diakses mesti menunggu penyelesaian transaksi sebelumnya. sebelum ia boleh terus dilaksanakan (selesaikan bacaan kotor, bacaan tidak boleh diulang dan bacaan hantu)

Keselamatan diserahkan mengikut urutan, dan prestasi dikurangkan mengikut urutan

3 .Andaikan ada ialah hanya satu lajur dalam jadual data T, dan nilai satu baris ialah 1

create table T(c int) engine=InnoDB;
insert into T(c) values(1);

Berikut ialah gelagat melaksanakan dua transaksi dalam susunan kronologi:

• Jika tahap pengasingan dibaca tanpa terikat, maka V1 ialah 2. Pada masa ini, walaupun transaksi B masih belum diserahkan, keputusannya telah dilihat oleh A. Kedua-dua V2 dan V3 ialah 2
• Jika tahap pengasingan adalah read-commit, maka V1 ialah 1 dan V2 ialah 2. Kemas kini transaksi B hanya boleh dilihat oleh A selepas ia dilakukan. V3 juga 2
• Jika tahap pengasingan boleh dibaca berulang, maka V1 dan V2 ialah 1, dan V3 ialah 2. Sebab mengapa V2 ialah 1 ialah data yang dilihat semasa pelaksanaan urus niaga mestilah konsisten
• Jika tahap pengasingan adalah bersiri, nilai V1 dan V2 ialah 1, dan V3 ialah 2

Dari segi pelaksanaan, paparan akan dibuat dalam pangkalan data, dan hasil logik paparan akan diutamakan apabila mengakses. Di bawah tahap pengasingan baca berulang, paparan ini dibuat apabila transaksi bermula dan digunakan sepanjang transaksi. Di bawah tahap pengasingan komit baca, pandangan ini dibuat pada permulaan setiap pernyataan SQL. Di bawah tahap pengasingan tidak terikat dibaca, nilai terkini pada rekod dikembalikan secara langsung, tanpa konsep pandangan manakala di bawah tahap pengasingan bersiri, penguncian digunakan secara langsung untuk mengelakkan akses selari

3. Pelaksanaan pengasingan transaksi (Ambil bacaan berulang sebagai contoh)

Dalam MySQL, setiap rekod akan merekodkan operasi rollback apabila ia dikemas kini. Nilai terkini pada rekod, melalui operasi rollback, boleh mendapatkan nilai keadaan sebelumnya

Katakan nilai ditukar daripada 1 kepada 2, 3, 4 mengikut tertib, akan ada dalam log rollback Serupa kepada rekod berikut

nilai semasa ialah 4, tetapi apabila menanyakan rekod ini, urus niaga bermula pada masa yang berbeza akan mempunyai paparan baca yang berbeza. Seperti yang anda lihat dalam rajah, dalam paparan A, B, dan C, nilai rekod ini masing-masing adalah 1, 2, dan 4 Rekod yang sama boleh wujud dalam berbilang versi dalam sistem, iaitu berbilang-. kawalan konkurensi versi (MVCC) pangkalan data ). Untuk read-viewA, untuk mendapatkan 1, anda mesti melakukan semua operasi rollback dalam rajah pada nilai semasa sekaligus untuk mendapatkan

Walaupun terdapat transaksi lain yang menukar 4 kepada 5, transaksi ini adalah berbeza daripada baca -Urus niaga yang sepadan dengan paparan A, B dan C tidak akan bercanggah

系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志会被删除

四、事务启动的方式

MySQL的事务启动方式有以下几种：

• 显示启动事务语句，begin或start transaction。提交语句是commit，回滚语句是rollback
• set autocommit=0，这个命令将这个线程的自动提交关掉。意味着如果只执行一个select语句，这个事务就启动了，而且不会自动提交事务。这个事务持续存在直到主动执行commit或rollback语句，或者断开连接

建议使用set autocommit=1，通过显示语句的方式来启动事务

可以在information_schema库中的innodb_trx这个表中查询长事务，如下语句查询持续时间超过60s的事务

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

五、事务隔离还是不隔离

下面是一个只有两行的表的初始化语句：

mysql> CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `k` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1),(2,2);

事务A、B、C的执行流程如下，采用可重复读隔离级别

begin/start transaction命令：不是一个事务的起点，在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动，一致性视图是在执行第一个快照读语句时创建的

start transaction with consistent snapshot命令：马上启动一个事务，一致性视图是在执行这条命令时创建的

按照上图的流程执行，事务B查到的k的值是3，而事务A查到的k的值是1

1、快照在MVCC里是怎么工作的？

在可重复读隔离级别下，事务启动的时候拍了个快照。这个快照是基于整个库的，那么这个快照是如何实现的？

InnoDB里面每个事务有一个唯一的事务ID，叫做transaction id。它在事务开始的时候向InnoDB的事务系统申请，是按申请顺序严格递增的

每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记作row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。也就是说，数据表中的一行记录，其实可能有多个版本，每个版本有自己的row trx_id

下图是一个记录被多个事务连续更新后的状态：

语句更新生成的undo log（回滚日志）就是上图中的是哪个虚线箭头，而V1、V2、V3并不是物理上真实存在的，而是每次需要的时候根据当前版本和undo log计算出来的。比如，需要V2的时候，就是通过V4依次执行U3、U2算出来的

按照可重复读的定义，一个事务启动的时候，能够看到所以已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。在实现上，InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前在启动了但还没提交的所有事务ID。数组里面事务ID的最小值记为低水位，当前系统里面已经创建过的事务ID的最大值加1记为高水位。这个视图数组和高水位就组成了当前事务的一致性视图。而数据的可见性规则，就是基于数据的row trx_id和这个一致性视图的对比结果得到的

这个视图数组把所有的row trx_id分成了几种不同的情况

对于当前事务的启动瞬间来说，一个数据版本的row trx_id，有以下几种可能：

1）如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的

2）如果落在红色部分，表示这个版本是由将来启动的事务生成的，肯定不可见

3）如果落在黄色部分，那就包括两种情况

• 若row trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见
• 若row trx_id不在数组中，表示这个版本是已经提交了的事务生成的，可见

InnoDB利用了所有数据都有多个版本的这个特性，实现了秒级创建快照的能力

2、为什么事务A的查询语句返回的结果是k=1？

假设：

1.事务A开始时，系统里面只有一个活跃事务ID是99

2.事务A、B、C的版本号分别是100、101、102

3.三个事务开始前，(1,1)这一行数据的row trx_id是90

Dengan cara ini, tatasusunan transaksi A ialah [99,100], tatasusunan paparan transaksi B ialah [99,100,101] dan tatasusunan paparan transaksi C ialah [99,100,101,102]

Daripada Seperti yang anda lihat dalam rajah di atas, kemas kini sah pertama ialah transaksi C, yang menukar data daripada (1,1) kepada (1,2). Pada masa ini, baris trx_id versi terkini data ini ialah 102 dan versi 90 telah menjadi versi sejarah

Kemas kini kedua yang berkesan ialah transaksi B, yang menukar data daripada (1,2) kepada ( 1,3). Pada masa ini, versi terkini data ini ialah 101 dan 102 telah menjadi versi sejarah

Apabila transaksi A membuat pertanyaan, transaksi B masih belum diserahkan, tetapi versi (1,3) yang dijana telah been telah menjadi versi semasa. Tetapi versi ini mesti tidak kelihatan kepada transaksi A, jika tidak, ia akan menjadi bacaan kotor

Sekarang transaksi A mahu membaca data dan tatasusunan paparannya ialah [99,100]. Membaca data bermula daripada versi semasa. Oleh itu, proses membaca data transaksi Pernyataan pertanyaan adalah seperti berikut:

• Apabila mencari (1,3), ditentukan bahawa baris trx_id=101, yang lebih besar daripada paras air yang tinggi, berada di kawasan merah, dan tidak kelihatan
• Kemudian, cari versi sejarah sebelumnya dan lihat baris trx_id=102, yang lebih besar daripada paras air tinggi, di kawasan merah dan tidak kelihatan
• Lihat lebih jauh dan akhirnya temui (1,1 ), barisnya trx_id=90, yang lebih kecil daripada paras air rendah dan berada di kawasan hijau Ia boleh dilihat bahawa

Walaupun baris ini data telah diubah suai dalam tempoh tersebut, tidak kira apabila transaksi A membuat pertanyaan, ia akan melihat baris ini Hasil data adalah konsisten Kami memanggilnya bacaan yang konsisten

Sebagai tambahan untuk paparan transaksi untuk kemas kininya sendiri sentiasa kelihatan, terdapat tiga situasi:

• Versi belum diserahkan dan tidak kelihatan
• Versi telah diserahkan, tetapi telah diserahkan selepas paparan telah dicipta dan tidak kelihatan
• Versi telah diserahkan dan ia telah diserahkan sebelum paparan dibuat. Dapat dilihat bahawa tatasusunan paparan

pernyataan pertanyaan transaksi A dijana. apabila transaksi A dimulakan Pada masa ini:

• (1,3) belum diserahkan lagi dan tergolong dalam Kes 1, tidak kelihatan
• (1,2) diserahkan, tetapi ia diserahkan selepas tatasusunan pandangan dibuat, yang tergolong dalam kes 2, halimunan
• (1,1) berada dalam paparan Dihantar sebelum tatasusunan dibuat, anda boleh lihat

3. Mengapakah pernyataan pertanyaan transaksi B mengembalikan k=3?

Apabila transaksi B ingin mengemas kini data, ia tidak lagi boleh mengemas kini pada versi sejarah, jika tidak kemas kini transaksi C akan hilang. Oleh itu, set k=k 1 transaksi B pada masa ini adalah operasi berdasarkan (1,2)

Data yang dikemas kini dibaca dahulu dan kemudian ditulis, dan bacaan ini hanya boleh Membaca nilai semasa dipanggil bacaan semasa. Sebagai tambahan kepada penyata kemas kini, jika penyata pilih dikunci, ia juga akan menjadi bacaan semasa

Bagaimana jika transaksi C tidak diserahkan serta-merta, tetapi menjadi transaksi C’ berikut?

Dalam rajah di atas, transaksi C tidak diserahkan serta-merta selepas kemas kini Sebelum diserahkan, penyata kemas kini transaksi B telah dimulakan terlebih dahulu. Walaupun transaksi C masih belum diserahkan, versi (1,2) juga telah dihasilkan dan merupakan versi terkini

Pada masa ini, protokol kunci dua peringkat terlibat, dan transaksi C belum diserahkan, iaitu ( 1,2) Kunci tulis pada versi ini belum dikeluarkan lagi. Dan transaksi B ialah bacaan semasa, ia mesti membaca versi terkini, dan ia mesti dikunci, jadi ia mesti menunggu sehingga transaksi C melepaskan kunci sebelum ia boleh meneruskan bacaan semasanya

7 Bagaimanakah keupayaan membaca berulang bagi transaksi dicapai?

Inti bacaan berulang ialah bacaan yang konsisten; apabila transaksi mengemas kini data, hanya bacaan semasa boleh digunakan. Jika kunci baris rekod semasa diduduki oleh transaksi lain, anda perlu memasukkan kunci tunggu

Logik komit baca adalah serupa dengan logik bacaan boleh berulang Perbezaan utama antara mereka ialah:

Di bawah tahap pengasingan baca yang berulang, anda hanya perlu membuat pandangan konsisten pada permulaan urus niaga. tahap pengasingan komit baca, setiap pernyataan Pandangan baharu akan dikira berulang kali sebelum pelaksanaan
• Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati:
Video Pengaturcaraan

! !

Atas ialah kandungan terperinci Mari berbincang dengan anda tentang pengasingan transaksi dalam MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!