Locks in transactions, row locks and table locks

When executing a transaction, it is equivalent to executing a lock to maintain data consistency, but there are various types of locks, including row locks and table locks. A row lock is to lock only that row, that record, and operations under other connections can also operate this table. A table lock is to lock the entire table, and it can only be unlocked after the current connection executes the transaction.

 

As far as efficiency is concerned, of course, row locks are good, suitable for multi-threading and high concurrency situations, but row locks will bring additional overhead to the database. Table locks are a little bit more concurrency with high concurrency, but a single one is faster.

 

Taking mysql as an example, when there is an index and the index is used, it is a row lock , and when there is no index, it is a table lock . Innodb  's row lock is in the case of an index , and a table without an index locks the entire table .

 

The lock is for other connections, not for the current connection, that is, the current connection can be updated all the time without rollback , commit , but other connections cannot, and must wait for the connection with the lock to be released ( rollback , commit ) before update, insert

 

Recommendation: For insert operations, generally add table locks, but for modification and deletion operations, it is best to add row locks, so that you don't have to wait too long in high concurrency

 

Locking method:

select * from testlock where id=1 for update; - query lock, no changes are allowed during query, the statement takes effect when auto commit is off or transaction, which is equivalent to change operation, simulating lock

update testlock name=name; --column = same column

Update operations, insert, delete operations are all locked in a transaction

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326168133&siteId=291194637