Transaction and mechanism of database

1. Four characteristics of database transactions (ACID)

1. Atomicity

    Atomicity means that all operations included in the transaction either succeed or fail and roll back, and there will be no half-success and half-failure;

2. Consistency

    Consistency means that a transaction must bring the database from one consistent state to another consistent state, that is, a transaction must be in a consistent state before and after execution.

 Take the transfer as an example, assuming that the sum of the money of user A and user B is 5,000, then no matter how the money is transferred between A and B, after several transfers, the sum of the money of the two users should be returned after the transaction is over. is 5000, which is the consistency of the transaction.

3. Isolation

    Isolation means that when multiple users access the database concurrently, such as when operating the same table, the transaction opened by the database for each user cannot be interfered by the operations of other transactions, and multiple concurrent transactions must be isolated from each other.

4. Durability

    Durability means that once a transaction is committed, the changes to the data in the database are permanent, and the operation of committing the transaction will not be lost even if the database system encounters a failure.

 

2. Transaction isolation level

1. Abnormal situation

    First look at the concentration that would occur without transaction isolation;

(1) Dirty read

    Dirty read refers to reading data from another uncommitted transaction during one transaction.

update account set money=money+100 where name=’B’;

update account set money=money - 100 where name=’A’;

Suppose A repays 100 yuan to B, submits the request and executes the above sql without submitting the transaction, and then informs B that it has been transferred;

At this time, B queries the account:

select money from account where name = 'A';

It is found that the money has indeed arrived in the account, and reply B received it;

At this time, A rolls back the transaction, and when B wants to use the money, he finds that the money is gone...

(2) Non-repeatable read

    Non-repeatable read means that for a certain data in the database, multiple queries within the scope of a transaction return different data values, because it is modified and committed by another transaction during the query interval.

    When transaction A is in the middle of reading data twice, transaction B submits a modification, resulting in inconsistent results of two readings by transaction A;

(3) Virtual reading (phantom reading)

    The number of records read twice within a transaction is different; unlike dirty reads, dirty reads read data items, while phantom reads read the number of records, such as the number of rows; but the same is to read data that has been committed by the previous transaction;

2. Four isolation levels

Read Uncommitted Minimum level, no guarantee in any case  
Read Committed Avoid dirty reads Oracle default
Repeatable Read Avoid dirty reads and non-repeatable reads MySQL default
Serializable (serialization) Avoid dirty reads, non-repeatable reads, and phantom reads  

Query the current MySql isolation level:

select @@tx_isolation;

Set MySql isolation level:

set tx_isolation=’隔离级别名称’

 

3. Database lock mechanism

Locks include row-level locks, table-level locks, pessimistic locks, and optimistic locks;

1. Row-level lock (for update)

INSERT、UPDATE、DELETE、SELECT … FOR UPDATE [OF columns] [WAIT n | NOWAIT];
SELECT… FOR UPDATE;

The above statement allows users to lock multiple record updates at a time. Use to release the lock from commit or rollback;

Demo:

SHOW VARIABLES LIKE 'autocommit'; //查看当前提交模式
SET autocommit = off //取消自动提交改为手动提交

Execute in a database connection:

Execute in another database connection:

You can see that the execution is waiting... (the execution result is the display after waiting for a long time);

At this time, when the first database connection executes commit or rollback, the second connection has the result;

2. Table-level locks

 

    to be continued... ...

 

    (2) Gap lock (Next-Key lock)

    The following sql will only lock records that meet the condition of id = 1,

SELECT * FROM tabletest WHERE id = 1 FOR UPDATE

    But this sql will lock records that satisfy id > 10, assuming that there are only 12 records in the database with id = 1, 2, 3, ... 10, 11, 12, it will also lock 13, 14, etc. locks, even if they don't currently exist;

SELECT * FROM tabletest WHERE id > 10 FOR UPDATE

Demo:

Original database data:

Execute sql:

SELECT * FROM tabletest WHERE id > 0 FOR UPDATE

This sql will lock all records with id>0;

we perform

INSERT INTO tabletest VALUES(3,'5555',CURRENT_TIME,6)

It can be seen that the lock is waiting, indicating that the records that did not exist are also locked by the row. Normally, we do not want this;

       Therefore, in actual development, especially for applications with many concurrent inserts, we should try our best to optimize business logic, use equality conditions to access updated data, and avoid using range conditions.

 

 

 

 

 

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325020525&siteId=291194637