The mysql lock question has been asked several times during the interview. I have read related blogs before, but it is always easy to forget if I simply read it. Here is a summary of the knowledge points of the mysql lock interview.
1. Storage engine (two common MyISAM and InnoDB)
MyISAM: Only table-level locks are supported. When the user operates the myisam table, the select, update, delete, and insert statements will automatically lock the table. If the locked table meets the insert concurrency, you can insert a new one at the end of the table The data.
InnoDB: Support for transactions and row-level locks is the biggest feature of InnoDB. Row locks greatly improve the new capabilities of multi-user concurrent operations. However, InnoDB's row lock is based on indexes. Only when data is retrieved through index conditions, InnoDB uses row-level locks. Otherwise, InnoDB will use table locks!
2. There are three types of mysql locks:
Table lock features: low overhead, fast locking, no deadlock, large locking granularity, the highest probability of lock conflicts, and the lowest concurrency
Row lock characteristics: high overhead, slow locking, deadlocks, small locking granularity, the lowest probability of lock conflicts, and the highest concurrency
Page lock features: overhead and lock time are between table locks and row locks, deadlocks will occur, locking granularity between table locks and row locks, and general concurrency
1. Table lock
1.1, the lock mode of MySQL table-level lock
MySQL's table-level lock has two modes: table shared read lock (Table Read Lock) and table exclusive write lock (Table Write Lock). Lock mode compatibility:
read operations on MyISAM tables will not block other users' read requests to the same table, but will block write requests to the same table;
write operations on MyISAM tables will block other users from the same table The read and write operations of the
MyISAM table are serialized between read and write operations, and between write operations. When a thread obtains a write lock on a table, only the thread holding the lock can update the table. The read and write operations of other threads will wait until the lock is released.
1.2, how to add table lock
For MyISAM engine
selectBefore execution , all tables involved will be automatically read- Performing updates (update, delete, insert) will automatically add writes to the tables involved
No need for the user to directly use the lock tablecommand explicitly
For the explicit locking of MyISAM, it is generally to simulate transaction operations to a certain extent, to achieve consistent reading of multiple tables at a certain point in time
1.3, you can use concurrent_insert to control concurrent insertion
2. Row lock
2.1, InnoDB lock mode and implementation mechanism
InnoDB's row-level locks are also divided into two types, shared locks and exclusive locks. In order to allow row-level locks and table-level locks to coexist during the implementation of the locking mechanism, InnoDB also uses intentional locks (table-level locks). Concept, there are two kinds of intention shared locks and intention exclusive locks.
When a transaction needs to lock a certain resource it needs, if it encounters a shared lock that is locking the resource it needs, you can add another shared lock, but you cannot add an exclusive lock. However, if you encounter that the resource you need to lock is already occupied by an exclusive lock, you can only wait for the lock to release the resource before you can acquire the locked resource and add your own lock. The role of the intention lock is that when a transaction needs to acquire a resource lock, if the resource it needs is already occupied by an exclusive lock, the transaction can add a suitable intention lock to the table that locks the row. If you need a shared lock, add an intent shared lock to the table. And if what you need is to add an exclusive lock on a certain row (or certain rows), first add an intent exclusive lock on the table. Multiple intent shared locks can coexist at the same time, but only one intent exclusive lock can exist at the same time. Therefore, it can be said that the lock mode of InnoDB can actually be divided into four types: shared lock (S), exclusive lock (X), intention shared lock (IS) and intention exclusive lock (IX). We can summarize the above by the following table The logical relationship of the coexistence of these four types of institutions:
If the lock mode requested by a transaction is compatible with the current lock, InnoDB grants the requested lock to the transaction; otherwise, if the two are incompatible, the transaction waits for the lock to be released.
The intention lock is automatically added by InnoDB without user intervention.
The default data modification statement of the mysql InnoDB engine, update, delete, and insert will automatically add exclusive locks to the data involved. The select statement does not add any lock type by default. If you add an exclusive lock, you can use the select...for update statement. To add a shared lock, you can use the select... lock in share mode statement.
Therefore, data rows with exclusive locks cannot be modified in other transactions, and data cannot be queried through for update and lock in share mode, but data can be queried directly through select...from..., because There is no lock mechanism for ordinary queries.
2.2. InnoDB row lock implementation
InnoDB row lock is implemented by locking the index items on the index. Only when data is retrieved through index conditions, InnoDB uses row-level locks. Otherwise, InnoDB will use table locks
in actual applications. Pay special attention to this feature of InnoDB row locks, otherwise, it may cause a large number of lock conflicts, thereby affecting concurrency performance. Here are some practical examples to illustrate.
(1) When querying without index conditions, InnoDB does use table locks instead of row locks.
(2) Because MySQL row locks are locks for indexes, not records, although records of different rows are accessed, if the same index key is used, there will be lock conflicts.
(3) When the table has multiple indexes, different transactions can use different indexes to lock different rows. In addition, whether it is using primary key indexes, unique indexes or ordinary indexes, InnoDB will use row locks to lock data.
(4) Even if the index field is used in the condition, whether to use the index to retrieve data is determined by MySQL by judging the cost of different execution plans. If MySQL thinks that the full table scan is more efficient, such as for some small tables , It will not use indexes. In this case, InnoDB will use table locks instead of row locks. Therefore, when analyzing lock conflicts, don't forget to check the SQL execution plan to confirm whether the index is actually used.
2.3. Gap lock (Next-Key lock)
When we use range conditions instead of equal conditions to retrieve data and request a shared or exclusive lock, InnoDB will lock the index items of the existing data records that meet the conditions;
for the key value Records that are within the scope of the condition but do not exist are called "gap (GAP)". InnoDB will also lock this "gap". This lock mechanism is the so-called gap lock (Next-Key lock).
2.4, deadlock
MyISAM table lock is deadlock free, this is because MyISAM always obtains all the locks it needs at once, either all of them are satisfied or waiting, so there will be no deadlock. However, in InnoDB, except for transactions composed of a single SQL, locks are gradually acquired. When two transactions need to acquire an exclusive lock held by the other party to continue the transaction, this cyclic lock wait is a typical deadlock.
In InnoDB's transaction management and locking mechanism, there is a mechanism for specifically detecting deadlocks, which will detect the deadlock within a short time after the deadlock occurs in the system. When InnoDB detects a deadlock in the system, InnoDB will select the smaller of the two transactions that caused the deadlock to roll back through corresponding judgments, and let the other larger transaction complete successfully.
So how does InnoDB determine the size of a transaction? This problem is also mentioned in the official MySQL manual. In fact, after InnoDB finds a deadlock, it calculates the amount of data inserted, updated, or deleted by the two transactions to determine the size of the two transactions. That is to say, the more records a transaction changes, the less it will be rolled back in a deadlock.
2.5, InnoDB row lock optimization suggestions
InnoDB storage engine due to the realization of row-level locking, although the performance loss caused by the implementation of the locking mechanism may be higher than the table-level locking, but it is farther in terms of overall concurrent processing capabilities Far better than MyISAM's table-level locking. When the system concurrency is high, the overall performance of InnoDB will have obvious advantages compared with MyISAM. However, InnoDB's row-level locking also has its fragile side. When we use it improperly, the overall performance of InnoDB may not only be higher than that of MyISAM, but may even be worse.
(1) In order to make reasonable use of InnoDB's row-level locking to maximize strengths and circumvent weaknesses, we must do the following:
a) As far as possible, all data retrieval is done through indexes, so as to avoid InnoDB being unable to lock through index keys. Upgrade to table-level locking;
b) Reasonably design the index to make InnoDB as accurate as possible when locking on the index key, reduce the lock range as much as possible, and avoid unnecessary locking and affect the execution of other Query;
c) As much as possible Reduce the range-based data retrieval filter conditions to avoid locking records that should not be locked due to the negative effects of gap locks;
d) Try to control the size of the transaction, reduce the amount of locked resources and the length of the lock time;
e) In the business environment When allowed, try to use lower-level transaction isolation to reduce the additional cost of MySQL due to the implementation of the transaction isolation level.
(2) Due to InnoDB's row-level locking and transactional nature, deadlocks will definitely occur. Here are some commonly used tips to reduce the probability of deadlocks:
a) In similar business modules, try to follow the same access order as possible Access to prevent deadlock;
b) In the same transaction, try to lock all the resources needed at once to reduce the probability of deadlock;
c) For the business part that is very prone to deadlock, you can try to use upgrade lock Granularity, through table-level locking to reduce the probability of deadlock.
(3) You can analyze the contention of the row lock on the system by checking the InnoDB_row_lock state variable:
Three, pessimistic lock and optimistic lock
The table shared read lock (Table Read Lock) and table exclusive write lock (Table Write Lock) of the MyISAM storage engine in the mysql database and the shared lock and exclusive lock of the InnoDB storage engine are all pessimistic locks. Optimistic locks are not built in the database and need We do it ourselves.
Java's pessimistic lock has two implementations, ReentrantLock and Synchronized, and optimistic lock is implemented by cas.
Reference: http://m.nowcoder.com/discuss/151430?type=0&pos=6