High-performance MySQL learning notes-lock, transaction, isolation level

ArticleDirectory

• From the data operation type (read/write)
• From the locked data range

Why do I need a lock?

Because the database needs to solve the concurrency control problem. At the same time, multiple clients may operate table1.rown. For example, some clients may read this row of data and others may try to delete it. To ensure data consistency, the database must control such concurrent operations, so there is a lock concept.

The lock category is divided from the data operation type (read/write ).

Read locks (shared locks): For the same piece of data, multiple read operations can be performed simultaneously without affecting each other.

Exclusive lock: when the current write operation is not completed, it will block other write locks and read locks.

From the locked data range

Table lock

Row lock

In order to improve the database concurrency as much as possible, the smaller the data range to be locked each time, the better. Theoretically, the solution that only locks the data of the current operation will get the maximum concurrency, however, the management lock is a resource-consuming task (involving operations such as obtaining, checking, and Releasing locks). Therefore, the database system must balance the high concurrency response and system performance, in this way, the concept of "lock granularity" is introduced.

Lock Granularity)

Table lock: The minimum management lock overhead and the minimum allowed concurrency lock mechanism. The lock mechanism used by the MyISAM storage engine. When you want to write data, lock the entire table and wait for other read and write actions. In MySQL, apart from using this lock policy by the MyISAM storage engine, Mysql itself also uses table locks to execute certain specific actions, such as alter table.

Row lock: supports the maximum number of concurrent lock policies. Both InnoDB and Falcon adopt this policy.

MySQL is an open architecture. You can implement your own storage engine and implement your own lock granularity policies. Unlike Oracle, you have no chance to change the lock policy, oracle uses row locks.

Transaction)

From the business point of view, a set of database operations requires four features:

Atomicity: atomicity

Consistency: consistency,

Isolation: Isolation

Durability: Persistent

To better understand acid, take bank account transfer as an example:

1 start transaction;

2 select balance from checking where customer_id = 10233276;
3 Update checking set balance = balance-200.00 where customer_id = 10233276;
4 Update savings set balance = balance + 200.00 where customer_id = 10233276;
5 commit;

Atomicity: either full submission (10233276 of the checking balance is reduced by 200, and the savings balance is increased by 200) or full rollback (the balance of both tables does not change)

Consistency: the consistency in this example is shown in the figure that 200 yuan won't crash because the database system has run to 3rd rows and before 4th rows, because the transaction has not been committed.

Isolation: Operation statements in a transaction are allowed to be isolated from statements in other transactions. For example, when transaction a runs after 3rd and before 4th, transaction B queries the checking balance, it can still see the RMB 200 deducted from transaction a because transaction a and transaction B are isolated from each other. Before transaction a is committed, transaction B cannot observe the data changes.

Persistence: This is easy to understand.

Transactions and locks all require a lot of work. Therefore, you can decide whether to need transaction support based on your own needs and select different storage engines.

Isolation level)

 The SQL standard defines four isolation levels, including some specific rules to limit which changes inside and outside the transaction are visible and which are invisible. Low-level Isolation generally supports higher concurrent processing and lower system overhead.
Read uncommitted (read uncommitted content)

At this isolation level, all transactions can see the execution results of other uncommitted transactions. This isolation level is rarely used in practical applications, because its performance is no better than other levels. Read uncommitted data, also known as dirty read ).
Read committed (read submitted content)

This is the default isolation level for most database systems (but not for MySQL ). It satisfies the simple definition of isolation: a transaction can only see changes made by committed transactions. This isolation level also supports the so-called nonrepeatable read, because other instances of the same transaction may have a new commit during the processing of this instance, so the same select may return different results.
Repeatable read (repeable)

This is the default transaction isolation level of MySQL. It ensures that multiple instances of the same transaction will see the same data rows when reading data concurrently. However, theoretically, this will lead to another tricky problem: phantom read ). In short, phantom read refers to when a user reads data in a certain range, another transaction inserts a new row in this range. When the user reads data in this range, there will be a new Phantom line. The InnoDB and Falcon storage engines solve this problem through the Multi-version concurrency control (MVCC, multiversion Concurrency Control) mechanism.

Serializable (serializable) 
This is the highest isolation level. It forces transaction sorting to make it impossible to conflict with each other, thus solving the phantom read problem. In short, it adds a shared lock to each read data row. At this level, there may be a lot of timeout and lock competition.

The four isolation levels adopt different lock types. If the same data is read, problems may occur. For example:

Dirty read: a transaction has updated the data, and another transaction has read the same data at this time. For some reason, the previous rollback operation is performed, the data read by the other transaction is incorrect.

Non-Repeatable read: the data in the two queries of a transaction is inconsistent. This may be because the original data updated by a transaction is inserted in the two queries.

Phantom read: the number of data records in two queries of a transaction is inconsistent. For example, a transaction queries several rows of data, another transaction inserts several new columns of data at this time. In the subsequent query, the previous transaction will find that several columns of data are not at the beginning.

In MySQL, these four isolation levels are implemented, which may cause the following problems: