Transactions, four major characteristics of relational data transactions, transaction isolation level, MVCC, locking mechanism

affairs

A transaction is a complete database operation. This operation may include the execution of multiple SQLs. The execution of these multiple SQLs is a whole. Either they all execute successfully or they all fail.

Example: Transfer operation: transfer money from account A to account B. When account A is +100, account B must be -100.

Online order payment: place an order with the seller and pay with the platform

Only the innodb engine supports database transactions in MySQL

Transactions are used to manage insert, update, and delete statements.

Four major characteristics of relational data transactions

Generally speaking, transactions must meet four conditions (ACID): atomicity (also called indivisibility), consistency (Consistency), isolation (Isolation, also called independence), and durability (Durability).

Atomicity: Multiple operations during a transaction either all succeed or fail.

Durability: Once a transaction is committed, the data cannot be changed, even if there is a problem with the database service

Isolation: The database allows multiple transactions to be accessed at the same time. In this case, the operations between transactions need to be isolated.

​Isolation can be divided into 4 levels:

Read uncommitted problem: dirty read

Read committed to solve dirty read problem: non-repeatable read

Repeatable reading solves the problem of non-repeatable reading: phantom reading

​ Serialization to solve all problems is similar to locking and has low efficiency

Consistency: The integrity of the database is not compromised before the transaction begins and after the transaction ends.

For example: perform multiple simultaneous operations on bank account balances in multiple ways. The final balance should be the result we expected, and no errors can occur.

-- 设置MySQL事务的提交方式为手动提交
SET GLOBAL autocommit=0;

-- 查看事务提交模式
SHOW GLOBAL VARIABLES LIKE 'autocommit';

BEGIN;
	INSERT INTO test(NAME)VALUES("aaaaa");
	
	ROLLBACK;
	
	SELECT * FROM test;
	
	
	
BEGIN;
	INSERT INTO test(NAME)VALUES("aaaaa");
	
	SELECT * FROM test;
	
	COMMIT;
	
	SELECT * FROM test;

1. Read dirty data: Junk data is read and transaction A reads uncommitted data of transaction B.

2. After the non-repeatable read A transaction was started, the data was read twice, and the two data were different (the expected effect is that the data read by A in the same transaction is the same)

3. Phantom reading: The amount of data read twice after transaction A is started is inconsistent.

transaction isolation level

Read uncommitted: A can read B’s uncommitted data Problem: There will be dirty reads and almost no use

Read committed: A cannot read B's uncommitted data, but can only read B's submitted data. This solves the problem of dirty reads and also causes the problem of non-repeatable reads.

eg: Solve the dirty read problem

eg: brings about the problem of non-repeatable reading

Repeatable reading: After transaction A is started, after reading a certain data for the first time, then in this data, when the same data is queried for the second time, it is consistent with the original, and repeated reading solves the problem of non-repeatable reading.

After submitting the transaction, query again to get the latest data.

eg: Phantom reads will not occur in the corresponding Innodb engine in mysql8.0

Serialization: Solving all problems, allowing one transaction to operate on a value at a time is the safest and least efficient

MVCC

MVCC (Multi-Version Concurrent Control)

In order to improve the read-write and write-read operations of mysql, two operations, write-write, can be performed at the same time. Mysql supports row-level locks. If the same row of data is operated, it is definitely not possible.

Every time a record in the table is operated, a log (undolog) will be saved, which will record the ID number of the transaction.

If there are multiple transaction operations, they will find the version record of their operation based on the transaction ID.

Different isolation levels will generate a ReadView (temporary read view) version chain snapshot based on the version chain when reading data.

READ COMMITTED : A ReadView is generated every time before data is read, resulting in non-repeatable reading. When the data changes, the version chain will also be modified. The data in the ReadView changes every time it is read, so it is non-repeatable reading.

REPEATABLE READ : A ReadView is generated when the data is read for the first time. Then the data changes and the version chain changes. It doesn't matter. A picture was taken when reading the data for the first time.

lock mechanism

Locks in mysql are mainly used for write operations

, MySQL supports row locks, gap locks and table locks

Row lock : When a transaction writes a row record, the current row will be locked, and other transactions cannot operate on the current row.

The granularity is the smallest, the concurrency is the highest, and locks are frequently added and released.

Gap lock : locks an interval. When operating within a condition range, the interval data that meets the condition will be locked.

Table lock : When a certain transaction operates on a certain row record, the entire table can be locked. InnoDB rarely uses it. Myisam supports table locks.

**Shared lock (S lock)** also known as read lock

**Exclusive lock (X lock)** also known as write lock

When the query is necessary, you can also add an exclusive lock for the read operation select * from table name for update statement

1. Optimistic locking: It does not actually lock a row of records, but is implemented through a version number.

It is not locked and can be distinguished by the version number.

2. Pessimistic lock: The above row locks, gap locks, table locks, etc. are all pessimistic locks