S lock, English is Shared Lock, Chinese translation is shared lock, sometimes we also call it read lock, that is, Read Lock. S locks are shared, or non-blocking.
1. S lock
S lock, English is Shared Lock, Chinese translation is shared lock, sometimes we also call it read lock, that is, Read Lock. S locks are shared, or non-blocking.
When a transaction reads a record, it needs to acquire the S lock of the record first.
for example:
Transaction T1 adds an S lock to record R1, then transaction T1 can read the row of R1, but cannot modify R1, and other transactions T2 can continue to add S locks to R1, but cannot add X locks, only when the S lock on R1 The X lock can only be added after the lock is released.
Take an example of adding S lock, as shown in the figure below:
At this time, for the record with id=1, it can only be read but not modified. Assuming that in another transaction T, it is no problem to execute the following SQL, because the S lock is a shared lock, and the S lock and the S lock are compatible:
select * from user where id=1 lock in share mode;
But if you execute the following SQL, it will be blocked, because modifying data needs to acquire X lock, and S lock and X lock are not compatible:
update user set username='javaboy' where id=1;
The above update statement will acquire the X lock internally, and it will also block some query statements that manually add the X lock, such as the following:
It can be seen that the SQL is blocked after execution.
2. X lock
X lock, English is Exclusive Lock, Chinese translation is exclusive lock, sometimes we also call it write lock, that is, Write Lock. Like its name, X lock is exclusive, that is, a write lock will block other X locks and S locks.
When a transaction needs to modify a record, it needs to acquire the X lock of the record first.
for example:
Transaction T1 adds an X lock to record R1, then transaction T1 can read R1 and modify R1, while other transactions cannot add any locks to R1 until T1 releases the lock on R1.
As shown above, the format of locked read is as follows:
select .... for update;
3. Current read and snapshot read
From the above two locks, two kinds of reading are derived:
3.1 Snapshot read
Snapshot read (SnapShot Read) is a consistent read without locking, which is one of the core reasons why the InnoDB storage engine has such a high concurrency.
Under the isolation level of repeatable read, when the transaction starts, a photo (snapshot) will be taken for the current library, and the data read by the snapshot is either the data when the photo is taken, that is, the data in the database at the moment the transaction is started , or the data inserted/modified by the current transaction itself.
The unlocked queries we use every day are all snapshot reads, so I won't demonstrate this.
3.2 Current reading
Corresponding to the snapshot read is the current read. The current read is to read the latest data, not the historical version of the data. In other words, under the repeatable read isolation level, if the current read is used, other transactions can also be read. The data.
Song Ge gives an example:
A MySQL transaction opens two sessions A and B.
First start the transaction in session A and query the record with id 1:
Next, we modify the data with id 1 in session B, as follows:
Note that the B session should not open the transaction or open the timely commit transaction, otherwise the update statement will occupy an exclusive lock, which will cause blocking when the lock is used in the A session.
Next, go back to session A and continue query operations, as follows:
It can be seen that the first query in session A is a snapshot read, which reads the data status when the current transaction is started, and the latter two queries are current reads, which read the latest data (after modification in session B) The data).