Transaction Basics in MySQL

ACID properties of transactions

A transaction in MySQL refers to a mechanism for processing a set of SQL statements as an indivisible execution unit in database operations. Transactions have the characteristics of atomicity, consistency, isolation and durability (ACID characteristics).

1. Atomicity: All operations in a transaction are either executed successfully or rolled back on failure. If an error or interruption occurs during transaction execution, the system will undo the operations that have been performed and restore the data to the state before the transaction started.

2. Consistency: Before and after transaction operations, the database must maintain a consistent state. This means that the execution of the transaction will not violate the integrity constraints of the database, such as uniqueness constraints, foreign key constraints, etc.

3. Isolation: When multiple transactions are executed concurrently, the execution of each transaction should be isolated from the execution of other transactions, so that each transaction feels that it is operating data independently. This prevents data interference and inconsistent read issues between concurrent transactions.

4. Durability: Once a transaction is committed, its modifications will be permanently stored in the database, even if a system failure or database crash occurs, the data will not be lost.

To use a transaction, you first need to enclose a group of related SQL statements in the way of starting a transaction, usually using the or START TRANSACTIONstatement to start a transaction. Then, during execution, you can perform inserts, updates, deletes, etc. Finally, commit the results of the transaction to the database by executing, or undo all operations in the transaction by executing.BEGINBEGIN WORKCOMMITROLLBACK

START TRANSACTION;

INSERT INTO table1 (column1, column2) VALUES ('value1', 'value2');
UPDATE table2 SET column3 = 'value3' WHERE column4 = 'value4';

COMMIT;

By START TRANSACTIONstarting a transaction, then performing a series of insert and update operations, and finally committing COMMITthe transaction, these operations are made permanent. If an error occurs during the execution of the transaction, you can use ROLLBACKthe rollback transaction to undo the previous operation and restore the database to the state before the transaction started.

Transactions provide a powerful mechanism for handling complex database operations and ensuring data consistency and integrity.

transaction isolation level

data concurrency issues

1. Dirty Write (Dirty Write)
   For two transactions Session A and Session B, if transaction Session A modifies the data modified by another uncommitted transaction Session B
   , it means that dirty write has occurred

2. Dirty Read (Dirty Read)
   For two transactions Session A and Session B, Session A reads fields that have been updated by Session B but have not yet been committed.
   If Session B rolls back later, the content read by Session A is temporary and invalid.
   Session A and Session B each start a transaction. The transaction in Session B first updates the name column of the record whose studentno is 1 to 'Zhang
   San', and then the transaction in Session A queries the record with studentno as 1. , if the value of the column name is read as 'Zhang San', and
   the transaction in Session B is rolled back later, then the transaction in Session A is equivalent to reading a non-existent data, this phenomenon is
   called Dirty read.

3. Non-repeatable read (Non-Repeatable Read)
   For two transactions Session A and Session B, Session A reads a field, and then Session B updates the field. After
   Session A reads the same field again, the value is different. That means a non-repeatable read has occurred.
   We have submitted several implicit transactions in Session B (note that they are implicit transactions, which means that the transaction is submitted when the statement ends), these transactions have
   modified the value of the column name of the record whose studentno column is 1, and each transaction is submitted Later, if all transactions in Session A can view
   the latest value, this phenomenon is also called non-repeatable read.

4. Phantom reading (Phantom) For two transactions Session A and Session B, Session A reads a field from a table, and then Session B inserts some new rows
   in the table .
   Later, if Session A reads the same table again, there will be a few more rows. That means a phantom read has occurred.
   The transaction in Session A first queries the table student according to the condition studentno > 0, and obtains the record whose name column value is 'Zhang San';
   then an implicit transaction is submitted in Session B, which inserts an entry into the table student Afterwards, the transaction in Session A
   queries the table student according to the same condition studentno > 0, and the result set contains the record newly inserted by the transaction in Session B.
   This phenomenon is also called phantom reading. We call the newly inserted records phantom records.

transaction isolation level

The isolation level of a transaction refers to the degree of isolation between multiple concurrent transactions, which defines the visibility and influence of a transaction on another transaction.

In MySQL, there are four standard isolation levels, each with different characteristics and performance overhead. The isolation level can be set with the following command:

SET TRANSACTION ISOLATION LEVEL <isolation_level>;

The following are the four isolation levels supported by MySQL:

1. Read Uncommitted (Read Uncommitted): The lowest isolation level. A transaction can read uncommitted data that has not yet been committed by another transaction, which may cause the problem of dirty read (Dirty Read). This level has the best concurrency performance, but the lowest data consistency.

2. Read Committed (Read Committed): The default isolation level. A transaction can only read the data that another transaction has committed, avoiding the dirty read problem. But you may encounter non-repeatable read (Non-repeatable Read) and phantom read (Phantom Read) problems.

3. Repeatable Read: During the execution of a transaction, the same query will always return the same result set. This level avoids dirty reads and non-repeatable reads, but may encounter phantom reads. MySQL's default isolation level is repeatable read.

4. Serializable: The highest isolation level. Each transaction is executed sequentially, avoiding the problems of dirty reads, non-repeatable reads, and phantom reads. But the concurrency performance at the serialization level is the worst, because it prevents concurrent access.

The choice of isolation level needs to be weighed according to specific business needs and concurrency performance requirements. Lower isolation levels have better performance, but may cause data inconsistency problems; while higher isolation levels can provide stronger data consistency, but may reduce concurrent performance.

It should be noted that higher isolation levels are usually accompanied by greater lock overhead and resource competition, which may lead to deadlocks. Therefore, when choosing an isolation level, factors such as business requirements, data consistency requirements, and system performance need to be considered comprehensively.