MySQL's InnoDB storage engine supports transactions and row-level locks ( InnoDB's row locks are implemented by locking index entries ). Thanks to these features, the database supports high concurrency. What if InnoDB uses table locks instead of row locks to update data? Yes, InnoDB can be easily upgraded to a table lock, and then the concurrency will be greatly reduced.
There are three types of commonly used indexes: primary key, unique index, and common index. The primary key is indistinguishable, and it comes with the most efficient index attribute; the unique index refers to the attribute value with a repetition rate of 0, which can generally be used as a business primary key, for example: student number; the difference between the ordinary index and the former is that the attribute value has a repetition rate greater than 0 , cannot be used as the only specified condition, for example: student name.
Let me give the conclusion first : Under the Innodb engine, row locks are implemented based on locking index items, so the following points
- If the index item is not used in the where filter condition, it must be a table-level lock
- The primary key or unique index used when filtering conditions must be a row-level lock
- When ordinary indexes are used for filtering conditions, it is not necessarily a row-level lock. You have to check whether there is a large amount of data in the table and modify most of the data in the table. If so, mysql will change the row lock into a table lock, which is the ordinary index . The high data repetition rate causes the index to fail, and the row lock is upgraded to a table lock.
- Finally, you can use the expand execution plan to see how the execution efficiency is
row lock
- Disadvantages of row locks: high overhead; slow locking; deadlocks will occur
- The advantages of row locks: the granularity of locks is small, the probability of lock conflicts is low; the ability to handle concurrency is strong
- Locking method: automatic locking. For UPDATE, DELETE and INSERT statements, InnoDB will automatically add exclusive locks to the data sets involved; for ordinary SELECT statements, InnoDB will not add any locks; of course, we can also display locks:
- Shared lock: select * from tableName where … + lock in share more
- Exclusive lock: select * from tableName where … + for update
There are two biggest differences between InnoDB and MyISAM: first, InnoDB supports transactions; second, row-level locks are used by default. Locking can ensure transaction consistency
InnoDB uses row locks by default, and upgrades to table locks when querying without index fields. MySQL is not designed to dig holes for you. It has its own design purpose.
** Even if you use an index field in the condition, MySQL will consider whether to use the index according to its own execution plan (so there will be possible_key and key in the explain command). **If MySQL thinks that the full table scan is more efficient, it will not use the index. 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.
The first case: the whole table is updated. Transactions need to update most or all of the data, and the tables are relatively large. If row locks are used, transaction execution efficiency will be low, which may cause other transactions to wait for long locks and more lock conflicts.
The second case: multi-table cascade. Transactions involve multiple tables, and complex associated queries are likely to cause deadlocks, resulting in a large number of transaction rollbacks. In this case, if the tables involved in the transaction can be locked at one time, deadlocks can be avoided and the database overhead caused by transaction rollback can be reduced.
Case embodiment:
Mysql row locks are upgraded to table locks
MySQL prevents row locks from being upgraded to table locks