Row lock:
mysql and innodb use row locks. It will automatically lock each time it is inserted/updated.
mysql row lock is loaded based on index
The characteristics of row locks: low probability of lock conflicts and high concurrency, but there will be deadlocks.
Table lock:
myisam, the time table lock used
A table lock is a lock that locks an entire table. During the period when the table is locked, other transactions cannot operate on the table, and must wait for the current table lock to be released before the operation can be performed
Features: fast table lock, low performance
Exclusive lock:
If transaction T1 adds an exclusive lock to data object O1, then during the entire lock period, only transaction T1 is allowed to read and update O1, and no other transactions can perform any type of operation on this data object—— Until T1 released the exclusive lock.
Shared lock:
Shared locks are also called read locks, or S locks for short. As the name implies, shared locks are multiple transactions that can share a lock for the same data and can access the data, but can only be read but not modified.
note:
Update, delete, and insert will automatically add exclusive locks to the data involved, and the select statement will not add any lock types by default.
If you add an exclusive lock, you can use the select...for update statement, and if you add a shared lock you can use the select...lock in share mode statement.
Pessimistic Lock
As the name suggests, it is very pessimistic. Every time I get the data, I think that others will modify it , so every time I get the data, I will lock it , so that when others want to get the data, it will block until it gets the lock. Many such locking mechanisms are used in traditional relational databases, such as row locks, table locks, etc., read locks, write locks, etc., which are all locked before operations . It refers to a conservative attitude towards data being modified by the outside world (including other current transactions of the system and transaction processing from external systems). Therefore, the data is locked during the entire data processing process. The realization of pessimistic locking often relies on the locking mechanism provided by the database (and only the locking mechanism provided by the database layer can truly guarantee the exclusivity of data access, otherwise, even if the locking mechanism is implemented in this system, it cannot be guaranteed that the external system will not be modified. data).
Optimistic Lock
As the name implies, it is very optimistic. Every time I get the data, I think that others will not modify it , so it will not be locked. However, when updating, it will be judged whether others have updated the data during this period. You can use the version number, etc. Mechanism . Optimistic locking is suitable for multi-read application types, which can improve throughput. If the database provides a mechanism similar to write_condition, it is actually optimistic locking.
For example, optimistic locking is suitable for the case of relatively few writes, that is, when conflicts really rarely occur, which can save the overhead of locking and increase the overall throughput of the system.
However, if conflicts occur frequently, the upper-level application will continue to retry, which will actually reduce the performance, so in this case it is more appropriate to use a pessimistic lock.
Scenes:
The following hypothetical actual scenario can help us understand this problem more clearly:
suppose that when an online user places an order to buy a book, then there is an order in the database with an order number of 001, and one of the status fields is "valid". Indicates that the order is valid;The back-end manager inquired about the order of 001, and saw that the status was valid. The
user found that the order was wrong when placing the order, so he cancelled the order. Suppose you run this SQL: update order_table set status ='Cancel' where order_id = 001 ;The back-end manager sees that the status is valid at step b. At this time, although the user has cancelled the order at step c, the manager has not refreshed the interface, and the order status is still valid, so click "Delivery" "Button, send the order to the logistics department, and run a SQL similar to the following to change the order status to shipped: update order_table set status ='shipped' where order_id = 001
achieve:
Pessimistic lock:
Optimistic lock:
