Database lock module
What about the difference between MyISAM and InnoDB lock regard is?
- MyISAM is the default use of table-level locking, row-level locking is not supported ( at the time of operation of the database will only lock the rows are operated )
- InnoDB is the default with row-level locking, and also supports table-level locking ( in the operation of the database will lock the entire table )
- MyISAM does not support transactions
- InnoDB supports transactions
Used when not taking the index database operations are table-level locking
MyISAM
In this engine will default to add a table lock when the data select operation will add a table-level read lock for the table; when the update, insert, and delete operations will automatically add the table level write lock.
Applicable scene
- The number of rows frequently perform a full table count statement, MyISAM, there is a variable to hold the entire table
- Additions and deletions to the data frequency is not high (as additions and deletions will involve operation lock table), very frequently query
- No transaction scenes
InnoDB
In this engine will be used by default row lock, sharing and exclusive row-level locking to table-level locking of it is the same, but different scope of action, row-level locking effect only in the row is locked.
Applicable scene
- Data CRUD are quite frequent
- High reliability requirements, requiring support services
Database lock Classification
Read lock
Read lock is also known as shared lock , because one session to the database without blocking other session read a read operation, but will block write operations other sessions.
Back during the select operation plus for update will add exclusive lock plus lock in share mode will add a shared lock
Write lock
Write lock is also known as exclusive lock , when a session is added to the database after the write lock will block all other sessions of read and write operations.
The Add read / write lock
lock tables TABLE_NAME read/write；
Delete lock unlock tables
Page-level locking
Interposed between the table and row-level locks, the lock is positioned adjacent to the operation data in the data
Intent locks
When the transaction A locked table a row, transaction B if you want to apply for a write lock on the entire table, this is because the transaction data rows A row lock added, if the application is successful it will let the B and A occurs conflict. Therefore, when a transaction B locks need to determine the current distribution table database table has not been applied through the line or other transaction table lock, then it needs to be determined as follows:
1: Determine whether the table being used by other transactions with table locks table
2: Is there any line has been locked in the judgment table row lock.
In this case needs to be determined for the entire table is recorded in step 2, the efficiency is relatively low. Then there is the intention to lock in the presence of intent locks, any transaction or row on the table before the lock must first obtain intention locks, with the intent lock, the above inspection process becomes:
1: No change
2: get intent lock table
Intention to apply the lock operation is complete database, the database will automatically apply for intent table lock when the transaction were locked, we do not need to apply for programmers using code
Pessimistic locking
When we want to piece of data in a database can be modified in order to avoid the same time be modified by other people, the best way is to direct the data locked to prevent concurrent. This means the database locking mechanism, to lock before modifying the data, and then modify the way is called pessimistic concurrency control.
Optimistic locking
When the lock is relatively optimistic in terms of pessimistic locking, optimistic locking assumes that the data generally will not cause conflict, so submit updated data before formal conflict or not the data to detect a conflict if found, return error message to the user, allowing users to decide what to do.
ACID transaction
Atomicity (Atomicity): refers to the transaction is an indivisible unit of work operations in a transaction either occur or do not occur
Consistency (Consistency): the integrity of the data before and after the transaction must be consistent, it can be compared to the energy conservation law
Isolation (Isolation): refers to a plurality of users concurrent access to the database, the database for each user transaction open, operation not being disturbed by other transactions, for isolation between a plurality of concurrent transactions
Persistent (Durability): means that once a transaction is committed, he changed data in the database is permanent, then even if the database failure should not affect them
Concurrent access issues under the transaction isolation level and at all levels
View conversation transaction isolation levelselect @@tx_isolation
Setting Session isolation levelset session transaction isolation level read uncommitted
The higher the transaction isolation level, the higher the security, the more serious the serialized execution, reduce concurrency database. Oracle default is READ-COMMITTED, MySQL default is REPEATABLE-READ
Concurrent access problems caused by the transaction and how to avoid
1. Update loss -MySQL on all aspects of database transaction isolation level again can be avoided
Updating a transaction covered by another transaction update, the current mainstream database lock will take the initiative to avoid missing updates.
2. Dirty read more -READ-COMMITTED transaction isolation level to avoid
A transaction reads update data in another uncommitted transactions
3. Non-repeatable read more -REPEATABLE-READ transaction isolation level can be avoided
Multiple read operations to return results inconsistencies
4. The phantom read transaction isolation level can be avoided -SERIALIZALE
A plurality of read line transaction matches the search condition, transaction B changed by deletion or insertion of a result set A transaction
InnoDB Repeatable Read isolation level at how to avoid phantom read
Appearance: a snapshot reading (non-blocking reads) - pseudo MVCC
Current Reading
Plus a lock of CRUD statement: select ... lock in share mode, select ... for update, update, delete, insert
Snapshot read (isolation level in SERIALIZALE it can be established)
Unlocked non-blocking read, select, enhance the ability of concurrent execution, low-overhead, reading data may not be current version
Internal: next-key lock (line lock lock + gap)
Primary key index or unique index will lock it with Gap
- If the conditions where all the hits, you will not use Gap lock, the lock will only add records
- If the condition where part or all miss hits, locks will add Gap