Database Optimization Review (Chapter 3)

third chapter:

affairs

Transaction is the basic execution unit of operation in DBMS. Transaction itself is a limited sequence of database operations that constitute a single logical work unit, consisting of a set of DML statements INSERT, DELETE, and UPDATE.

In a relational database, a transaction can be a statement, a set of SQL statements, or an entire program.

The difference between a transaction and a program : a program contains multiple transactions.

Implicit transaction and automatic commit SQL statement

1. DDL语句：ALTER, CREATE, RENAME, DROP, TRUNCATE
2. User rights management operations : CREATE USER, GRANT, REVOKE, SET PASSWORD
3. Administrative statements : ANALYZE TABLE, CHECK INDEX, REPAIR TABLE, LOAD INDEX INTO CACHE

Order:

1. set autocommit=0 : Turn off transaction autocommit
2. begin : start the transaction
3. commit : commit the transaction
4. rollback : rollback transaction
5. start transaction : display open transactions

The InnoDB storage engine automatically commits transactions by default, and implicitly commits each row once , which is extremely slow and cannot be rolled back when an error occurs when a large number of inserts occur .

↑Optimize for this case, explicitly start the transaction and submit it , and put the loop body into the transaction to avoid circular submission.

The four major characteristics of ACID transactions

1. Atomicity : The operations in the transaction are either done or not done, and are indivisible. Atomicity is the essence and basic requirement of the transaction concept.
2. Consistency : The result of transaction execution must cause the database to change from one consistent state to another.
3. Isolation : Transactions executed concurrently cannot interfere with each other.
4. Durability : Once a transaction is committed, its updates to the database are no longer affected by subsequent operations or failures

transaction isolation level

Problems in transactional reading and writing

MySQL is a database accessed concurrently by multiple threads. When multiple users (multiple transactions) access the same database resources at the same time, that is, in a concurrent environment, the following uncertain situations may occur.

1. Dirty read : A transaction reads a row of data, and another transaction has updated the data of this row, but did not commit in time, **For example, transaction A reads the data updated by transaction B, and then transaction B due to some The reason is that the rollback operation is performed, then the data read by transaction A is dirty data. **This situation is very dangerous and may cause all operations to be rolled back.
2. Non-repeatable read : Non-repeatable read means that the modification and submission of one transaction causes the return results of two identical queries in the same range of another transaction to be different. For example, transaction A needs to read the same data multiple times, and before transaction A ends, transaction B accesses and modifies the data, then the data read by transaction A twice may be inconsistent, so it is called non- repeatable read.
3. Phantom reading : Phantom reading means that a transaction in one thread reads INSERT data submitted in another thread. For example, user A changes the grades of all students in the database from specific scores to ABCDE grades, but user B inserts a record of specific scores at this time. After the modification, user A finds that there is still a record that has not been changed. This situation is Phantom reading or phantom reading.

Transaction Isolation Levels in MySQL

characteristic	illustrate
ReadUncommitted read uncommitted	Allowing transactions to read the uncommitted results of other transactions (that is, allowing dirty reads) is the lowest and most dangerous transaction isolation level, and this level is rarely used in practical applications .
Read Committed Read Committed	Transactions are allowed to read only the committed results of other transactions. This isolation level can avoid dirty reads , but it cannot avoid repeated reads and phantom reads .
Repeatable Read repeatable read (default)	This level ensures that multiple instances of the same transaction can read the same data row when they read data concurrently. This level can avoid the problems of dirty reads and non-repeatable reads, but it cannot avoid the problems of phantom reads . It is the default isolation level of MySQL .
Serializable can be serialized	It is mandatory to sort transactions so that they cannot conflict with each other, thus solving the problem of phantom reading. In fact, this method adds a shared lock to each read data row , but this level may cause a large number of timeouts and lock competition , so it is rarely used in practical applications and is the highest isolation level in transactions

Order:

1. SELECT @@tx_isolation; View the isolation level of the current session (5.7)
2. SELECT @@transaction_isolation; View the isolation level of the current session (8.0)
3. SET SESSION TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}: Modify the isolation level of the current session.

lock mechanism

The lock mechanism is mainly to make the user 's access to the data orderly and ensure the consistency of the data . The lock mechanism is the easiest way to achieve high concurrency macroscopically, but from a microscopic point of view, the lock mechanism is actually serialization of reading and writing .

lock granularity

The granularity of the lock refers to the scope of the lock . The InnoDB storage engine supports table-level locks and row-level locks, and the MyISAM storage engine supports table-level locks.

Implicit and Explicit Locks

Automatic locking by MySQL is called implicit locking, and manual locking by database developers is called explicit locking.

MySQL read-write lock

Read lock: Read lock is also called shared lock , which allows other users to "read" data at the same time, but does not allow other users to "write" data at the same time

Write lock: Write lock is also called exclusive lock or exclusive lock. The write lock neither allows other users to "read" the data at the same time, nor does it allow other users to "write" the data at the same time

InnoDB lock type

Table-level lock : Table-level lock means that the entire table is locked by the client . Table-level locks are divided into read locks , write locks , and intent locks .

1. 命令：LOCK TABLES table_name[AS alias]{READ [LOCAL]|[LOS_PRIORITY]WRITE}
2. READ: Read lock, to ensure that users can read the table , but cannot modify the table .
3. WRITE: write lock, only the user who locked the table can modify the table , other users can only read the table .
4. Intention lock: The granularity of locking is the entire table. Intention lock means that if an intent lock is applied to a node, it means that the underlying nodes of the node are being locked. Intention locks are divided into two types: intent shared locks (IS) and intent exclusive locks (IX) . It is the lock that MySQL automatically adds to the table . The main function is to improve system performance . Otherwise, every time the second transaction wants to lock, it needs to check whether the table is locked, and then check whether the row is locked, which consumes a lot of performance.

Row-level locks : Only rows used by threads are locked . All other rows in the table are available to other threads. Row-level locks are divided into read locks and write locks .

1. READ: Read lock, to ensure that users can read the table , but cannot modify the table .
2. WRITE: write lock, only the user who locked the table can modify the table , other users can only read the table .
   

Gap lock: Gap lock (Gap Lock) is a lock mechanism introduced by the InnoDB engine under the repeatable read isolation level to solve the problems of phantom reading and data deletion . select * from test where id > 0 and id < 5 for update;, if there is no data with id 2 in the table (only 1, 3, 4), the data with id=2 is called "gap", InnoDB The engine also locks these "gaps". At this point, if transaction T2 executes the INSERT statement and inserts a piece of data with an id of 2, it needs to wait until the end of transaction T1 to insert successfully.

lock command

Set shared lock : SELECT * FROM table name WHERE condition LOCK IN SHARE MODE;

Set exclusive lock : SELECT * FROM table name WHERE condition FOR UPDATE; (InnoDB engine will automatically add exclusive lock to the default modification statement update, delete, insert)

lock waiting

Lock waiting means that during the execution of a transaction, a lock needs to wait until the lock of the previous transaction is released before using the resource.

parameter:

1. innodb_lock_wait_timout : lock waiting time parameter
2. select * from sys.innodb_lock_waits\G : View the occurrence of lock waiting
3. show full processlist : output thread id number

deadlock

In MySQL's InnoDB storage engine, when a deadlock is detected, a transaction that holds the least row-level exclusive lock is usually released and rolled back, while another transaction is allowed to acquire the lock and continue to complete the transaction.

Monitor transactions and locks

To view and monitor transaction and lock information, you can execute the show engine innodb status command.

MySQL records transaction and lock information in the information_schema database, we only need to query. There are mainly three tables involved, namely innodb_trx (check transaction status), innodb_locks (query lock status), innodb_lock_waits (check lock blocking status).

For versions above MySQL 5.6, you can set the innodb_print_all_deadlocks parameter to 1 to record deadlock information and put it in the error log.

Ways to Avoid Deadlocks

Ways to Avoid Deadlocks

(I) When different programs access multiple tables concurrently or involve multiple rows of records, try to agree to access the tables in the same order , which can greatly reduce the chance of deadlock.

(2) Adjust the application program. In some cases, by decomposing a large transaction into multiple small transactions , the lock can be released faster , and the transaction can be committed or rolled back in time, which can reduce the probability of deadlock.

(3) In the same transaction, try to lock all the resources needed at one time to reduce the probability of deadlock.

(4) Add a reasonable index to the table . If no index is used, each row of the table will be locked, and the probability of deadlock will be greatly increased.

(5) For businesses that are very prone to deadlocks, try to upgrade the lock granularity and reduce the probability of deadlocks through table locking.