Read-Write Lock
Mysql storage engine Innodb in dealing with concurrent read or write, to solve concurrency issues two types of locks, both locks are usually called shared locks and exclusive locks, also known as read and write locks.
Read lock is shared, that is, multiple clients can read the same resource at the same time.
Write lock is exclusive, which means that write locks block other write locks and read locks.
for example:
A read operation of the client need not wait for completion of reading the client B and releases the lock. But Client A while attempting to write, it will block other clients read and write operations until the client A write operation to complete and release the lock, other clients can read and write.
It says so much, but in fact when the client A to update a row of record at the same time, client B can read data of any course, will not be blocked, this is why?
The first to know two things, Redo Log (redo logs) and Undo Log (rollback log)
usually physical redo log log record is the physical page to modify the data, which is used to restore the physical page after submission data (restored data page, and can only be restored to the position of the last commit).
undo record to roll back to a version of the line. generally undo log logical logs recorded according to each recording line.
If you do not understand, so understanding: occurs when a write operation, Innodb will the old data stored in the Undo Log (rollback log), the new data is written to Redo Log (redo logs) in.
When the client A to update a row of record at the same time, client B will be blocked write locks, time, client B will go to Undo Log in to read the old data.
Let's practice the next.
CREATE TABLE `test001` (
`id` bigint(11) unsigned NOT NULL AUTO_INCREMENT,
`first_name` char(50) DEFAULT NULL,
`last_name` char(50) DEFAULT NULL,
PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
INSERT INTO `test001`(`id`, `first_name`, `last_name`) VALUES (1, 'fn001', 'ln001');
INSERT INTO `test001`(`id`, `first_name`, `last_name`) VALUES (2, 'fn002', 'ln002');
INSERT INTO `test001`(`id`, `first_name`, `last_name`) VALUES (3, 'fn003', 'ln003');
Executed in a terminal
BEGIN;
UPDATE test001 SET first_name='update_name' WHERE last_name='ln001';
Another terminal performs
SELECT * FROM `test001` WHERE last_name='ln001';
Queries can still get the data
ps: After the test is complete, remember to commit or rollback transaction ends.
Row-level locking
Innodb row-level locking, but this does not mean Innodb only locked modified row. Consider the following operations.
Perform a connection terminal
BEGIN;
UPDATE test001 SET first_name='update_name' WHERE last_name='ln001';
In another execution the terminal connection
BEGIN;
UPDATE test001 SET first_name='update_name2222' WHERE last_name='ln002';
Second SQL timeout is blocked, i.e. not update locked last_name = 'ln001' lines, other lines are also locked. In this case, in fact, we locked the entire table.
Rollback above things then the following operations. Run rollback
Why say Innodb implements row-level locking it? Let's add a line to the last_name index.
Just execute the statement again
Two non-interfering update statement can be seen, the index can be seen through Innodb screened out last_name = 'ln001' data line, and then only last_name = 'ln001' data line, locking the other data line is not is locked, so in this case can be updated last_name = 'ln002' data lines.
No pre-indexed, Innodb would not be able to specify filter out rows of data through indexes, only to lock the entire table.
