A, Mysql four isolation levels
1. Read uncommitted
User B did not commit the transaction, but A user was able to read uncommitted data, this is the dirty read .
2. Read Committed
Solve dirty read , the same transaction, read two different results. This has resulted in non-repeatable read , read the results of the two is different.
3 may be repeated degrees
Id would have the data 1 and 2, b has found two data query, data A is inserted id = 3, there are three query data A,
B have two data query, insert id = 3, given
said primary key is repeated, this time B user query and not just record id = 3. This is the phantom read phenomenon.
My understanding is: non-repeatable read refers to the update operation, and phantom reads refers to the insert or delete operation.
4. serialization
SERIALIZABLE highest isolation level. It is by forcing a transaction serial execution, avoiding the problem of phantom read said earlier. In simple terms, SERIALIZABLE will read each line of data is locked, it may cause a lot of timeouts and lock contention. Practical applications rarely use this isolation level, only in very necessary to ensure consistency of data and can accept no concurrent case, only consider that level.
Two, MVCC (multi-version concurrency control)
Locking mechanism may control the concurrent operation, but the overhead is large, and MVCC instead of row-level locks can, in most cases, MVCC, to reduce its overhead.
InnoDB is MVCC, is achieved by saving two hidden columns after each line record. The two columns, a preserved row creation time , saving a row of expiration time (or deletion time) , of course, are not storing the actual time value, but the system version number . Each start a new transaction, the system will automatically increment the version number. System version number will be the start time of the transaction as the version number of the transaction, and the version number to each row of the query to the record for comparison.
select: the following two conditions innodb returns the row data:
(1) create the version number of the row is less than equal to the current version number, it has been used to ensure that all operations performed prior to landing in the select operation.
(2) delete the version number of the row is greater than the current version or is empty. Delete the version number greater than the current version means that there is a concurrent transaction that line deleted.
insert: The version number is set to create a new row is inserted for the current version of the system.
delete: Delete to delete the version number of the line to set the version number of the current system.
update: do not perform in-place update, but converted to insert + delete. The version number is set to delete the old row is the current version number and insert the new line created and set the version number for the current version number.
Among them, write operations (insert, delete and update) execution, the system will need to increment the version number.
Since the old data is not really deleted, so the need for these data cleansing, innodb will open a background thread to perform cleanup work, specific rules will remove the version number is less than the current version of the system to delete the line, this process is called purge.
By MVCC to achieve a good transaction isolation can be achieved repeated read level, to achieve serializable must also be locked.
