Transaction Description:
In MySQL only uses Innodb database engine or database tables only support transactions . Transactions can be used to maintain the integrity of the database to ensure that the bulk of the SQL statements either all executed or not executed all. It can also be used to manage the affairs DDL, DML, DCL operations, such as insert, update, delete statement. Generally speaking, the transaction must meet four conditions (ACID):
Atomicity (Atomicity):
All operations up the transaction must be a logical unit, either all executed or all not be executed
Consistency (stability, consistency):
Database before and after the transaction execution state must be stable and consistent.
Isolation (isolation):
The transaction will not affect each other.
Durability (reliability, durability):
After the successful implementation of the transaction must be completely written to disk.
There are about three common operations :
BEGIN or the START TRANSACTION ; explicitly open a transaction;
Close the transaction:
A COMMIT ; may also be used COMMIT WORK, but the two are equivalent. COMMIT commits the transaction, and the database has called all modifications permanent;
ROLLBACK ; there may be used ROLLBACK WORK, but the two are equivalent. Rollback end user transaction and to withdraw all uncommitted changes under way;
In the MySQL command line of the default settings, the transactions are automatically submitted after that is to execute SQL statements COMMIT operation will be executed immediately. Therefore, to explicitly open a transaction advised to use the command BEGIN or START TRANSACTION, or the AUTOCOMMIT = 0 Run the SET , to disable the automatic submission using the current session.
Transaction concurrency:
In matters of concurrent operation may be some problems:
Dirty read: A transaction reads data to another uncommitted transactions.
Non-repeatable read: A transaction to read another transaction because the data has been submitted . Resulting in more than twice the result with a record reading of inconsistency. update operation
Phantom read: a transaction to read another transaction because the data has been submitted . Resulting in more than twice the reading of the results of the same table inconsistent. insert, delete operation
Transaction Isolation:
In order to avoid the transaction concurrency issues arise, it defines four transaction isolation level in the standard sql planning, different isolation levels for different transactions.
From low to high:
① the Read Uncommitted (read uncommitted ): the lowest level, in any case can not be guaranteed.
② the Read committed (Read Committed ): can avoid dirty reads to occur.
③ Repeatable Read (Repeatable Read ): can prevent dirty reads, unrepeatable reads occurring.
④ the Serializable (serialization ): can prevent dirty reads, non-repeatable read, phantom read occurs.
Most database default isolation level is Read committed, such as the Oracle, the DB2 and so on.
MySQL database default isolation level is Repeatable read.
View the current transaction level:
select @@tx_isolation;
Set the transaction isolation level:
set [glogal | session] transaction isolation level isolation level name ;
set tx_isolation = 'name isolation level ;'
The higher the isolation level, the more it can ensure the integrity and consistency of the data, but the impact on concurrent performance is also greater.
For most applications, the database system can give priority to the isolation level to Read Committed. It is possible to prevent dirty reads, but also has better concurrent performance. Although it will lead to non-repeatable read, phantom read these concurrency problems, in individual cases such problems may occur, the application can be made using pessimistic locking or optimistic locking to control.
MySQL locks:
Due to its own MySQL database architecture, there are a variety of data storage engine, the storage engine characteristics of each application scenarios for which are not the same, in order to meet the needs of their specific application scenarios, each storage engine locking mechanism are for each face a particular scene and optimize the design, so the locking mechanism of each storage engine is also quite different, in general, MySQL storage engines each use three types (levels) of the locking mechanism: row-level locks , page-level lock and table-level locking . Let us first analyze the MySQL three locking features and pros and cons of each.
Row-level locking (row-level):
Row-level locking biggest feature is to lock the object is very small particles, is currently locked in major database management software to achieve the minimum granularity. Since the locking granularity is small, so the probability of occurrence locked resource contention is minimal, the application can give the greatest possible number of concurrent processing capability and improve concurrent applications that require high overall system performance. Even though it can have a greater advantage in the above concurrent processing capability, but row-level locking that brought a number of shortcomings. Since the locking granularity little resources, so every time things get and release locks also need to do more to bring the consumption of naturally greater. In addition, row-level locking is also the most prone to deadlock.
Table level lock (table-level)
And row-level locking Instead, the table-level locking is a MySQL storage engine in each maximum granularity of locking mechanism. The greatest feature of the locking mechanism is to implement logic is very simple, minimal negative impact on the system brings. So acquiring the lock and release the lock quickly. Due to a table-level lock will lock the entire table, it can be good to avoid deadlock plaguing us. Of course, the probability of lock contention resource lock large particles of the biggest is the emergence of the negative impact will be the highest, resulting in greatly reduced and generous.
MySQL table-level locking has two modes: a shared table read locks ( the Table the Read Lock) and table exclusive write locks ( the Table the Write Lock).
table_locks_immediate: frequency generating table-level locking;
table_locks_waited: table-level locking appears waiting times occur contention;
Manually increase the table and lock:
Lock Table Table Name Read ( Write ), the name of the table 2 Read ( Write ), the other ;
View table lock situation:
show open tables;
Delete table lock:
unlock tables;
Page-level locking (page-level):
Page-level locking in MySQL is a relatively unique locking levels, in other database management software also is not too common. Page-level locking granularity locking features between the row level locking table level lock, it is required to acquire the lock overhead resources, and can provide concurrent processing is also interposed between the two above. In addition, the page-level locking and row-level locking, as a deadlock occurs.
Table-level lock: Small overhead, lock fast; not deadlock; lock large size, the probability of lock conflicts of the highest, lowest degree of concurrency;
Row-level locking: large overhead, locking slow; there will be a deadlock; locking granularity smallest and lowest probability of lock conflicts, but also the highest degree of concurrency;
Page lock: locking overhead and time boundaries between the table and row locks; there will be a deadlock; locking granularity boundary between the table and row locks, concurrency in general.
InnoDB engine locking mechanism
InnoDB row lock is achieved by giving the index entries on the index lock, so InnoDB row lock to achieve this characteristic means: only through index conditions to retrieve the data, InnoDB only row-level locking. Otherwise, InnoDB will use table locks! .
InnoDB's row-level locking is also divided into two types, shared locks and exclusive locks , and in the locking mechanism of the implementation process in order to allow row-level locking and table-level locking coexist, InnoDB also uses intent locks (table-level locking) of concept, and we will have the intention of sharing the lock and intent exclusive lock both.
As used Innodb row level locking state Show: Show Status like 'innodb_row_lock%';
* Innodb_row_lock_current_waits: currently waiting the number of locks;
* Innodb_row_lock_time: Start now from a total time length of the locking system;
* Innodb_row_lock_time_avg: The average time spent waiting for a time;
* Innodb_row_lock_time_max: start from the system to the waiting time now spent most of the time;
* Innodb_row_lock_waits：系统启动后到现在总共等待的次数；
对于这5个状态变量，比较重要的主要是：
Innodb_row_lock_time_avg（等待平均时长）
Innodb_row_lock_waits（等待总次数）
Innodb_row_lock_time（等待总时长）这三项。
尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。