ACID refers to the acronym for the four basic elements in the correct execution of database transactions.
Specific explanation:
Atomicity, Consistency, Isolation, Durability
Any database transaction must satisfy ACID, only in this way can the correctness be guaranteed during transaction execution.
A transaction refers to a set of operations (database operations) performed as a single logical unit of work that either all succeed or all fail.
Local transactions refer to database transactions or traditional transactions. A transaction only connects to a database that supports transactions; the execution results of transactions guarantee ACID.
Distributed transaction means that in a distributed environment, an operation is coordinated by multiple systems, which may involve multiple database write operations (multiple data sources). Distributed transactions are to ensure data consistency in different databases (multiple data sources). sex.
Atomicity
Atomicity is actually very easy to understand. I think it refers to a kind of integrity, which means that any transaction with atomicity has only two states: completed operation and unoperational. Atomicity guarantees that all operations of a transaction either succeed together or fail together. Once an atomic transaction starts, it runs until it is finished, and it will not be interrupted by the thread scheduling mechanism. If a forced interruption is encountered, all will be rolled back to the original unoperated state. There is another saying: "atomic operation (atomic operation) is not needed".
Use Innodb's undolog (log rollback) to achieve atomicity. When the transaction is rolled back, all the SQL statements that have been successfully executed can be undone, and it needs to record the corresponding log information of the rollback (the undolog records the data before the operation).
Consistency
This is the core of database transactions, and it is the most basic feature of databases. This feature looks simple, but it is quite complicated to understand.
Its written definition is: consistent read and consistent write
Consistent read: Transaction read data can only be read from one state, not from two or more states
Consistent writing: Data changes executed by transactions can only be based on a consistent state and can only be reflected in one state.
A transaction must change the database from one consistent state to another, and the definition of consistency is related to integrity constraints (primary key, foreign key constraints, custom constraints, etc.). The legal data state before and after the transaction execution cannot violate any data integrity.
Isolation
The execution of a transaction cannot be interfered by other transactions. That is, the operations and data used within a transaction are isolated from other concurrent transactions, and the concurrently executed transactions cannot interfere with each other.
There are three fatal problems in concurrent data reading and writing:
(1) Dirty read:
Read uncommitted data from other transactions (uncommitted means that these data may be rolled back, and may not be stored in the database in the end).
(2) Non-repeatable read:
The data read by the same transaction using the same conditions multiple times is different (usually for update operations).
PS: Repeatable reading is MySQL's default transaction isolation strategy (level) that solves the problem of phantom reading, and it uses "gap locks".
(3) Phantom reading:
Transaction A reads data according to certain conditions, during which transaction B inserts/deletes new data with the same search conditions, transaction A reads again according to the original conditions, and finds the newly inserted data of transaction B; transaction A reads the same conditions twice The number of data read is different (usually for insert and delete operations).
Durability
Once a transaction is committed, its changes to the data in the database should be permanent and the data will not be lost.
Persistence is achieved through Innodb's redolog. If the data involved in multiple operations, it will be stored in the redolog, and finally the redolog data will be persisted to the disk; before the transaction is committed, the redolog will be persisted.
Standard SQL isolation level
| isolation level | dirty read | non-repeatable read | Phantom reading |
| Read uncommitted (read uncommitted) | possible | possible | possible |
| read committed | impossible | possible | possible |
| Repeatable reads (repeatable reads) | impossible | impossible | possible (not possible with MySQL) |
| Serial read (serializable) | impossible | impossible | impossible |
Completely serial read, which changes the execution of transactions into sequential execution, which is equivalent to a single thread. The execution of the latter transaction must wait for the end of the previous transaction. The isolation effect is the best, but it brings performance overhead and affects system performance.
MySQL transaction isolation is actually achieved by relying on locks. The read-uncommitted isolation level has the best performance without locks, but it cannot solve the problem.
Spring's five major transaction isolation levels and seven major transaction propagation behaviors
