MySQL InnoDB achieve high concurrency principle

MySQL principle chapter

Concurrency Control

Why would concurrency control?

Concurrent with the task of operating on a critical resource, if no measures are taken, could lead to inconsistencies, it must be concurrency control (Concurrency Control).

Technically, usually how concurrency control?

By concurrency control to ensure data consistency of the common means are:

锁（Locking）
Multi-data version (Multi Versioning)

lock

How to use ordinary locks ensure consistency?

Before the operation data, locked, mutually exclusive embodiment, the operation does not allow other concurrent tasks;
After the operation is completed, the lock is released to allow other tasks to perform;

Such and such, to ensure consistency.

What is wrong with ordinary lock?

Simple lock too rough, even the "read task" can not be parallel, the task execution is serial in nature.

So there is a shared lock and the exclusive lock:

A shared lock (Share Locks, as S lock), data is read lock was added S
Exclusive lock (eXclusive Locks, referred to as X lock), plus a lock when modifying data X

Shared lock and an exclusive lock is played:

Shared locks are not mutually exclusive, abbreviated as: read in parallel
Exclusive lock is exclusive of any locks, abbreviated as: write read, write, not in parallel

We can see that once the task is not completed writing data, the data can not be read by other tasks, which have a greater impact on the degree of concurrency.

Is it possible to further improve concurrency it?

Even writing task is not completed, the task may be complicated by other read, which leads to multiple versions of data.

Multiple versions of data

Data is a multi-version concurrency can be further improved methods, its core principles are:

When writing task occurs, the data clone copy of the version number to distinguish;
Write-tasking operating data for the new clone, until submission;
Concurrent reading tasks can continue to read the old version of the data, and will not clog;

As Figure:

Version of the beginning of the data is V0;
T1 time launched a writing task, which is a data clone, edit, version becomes V1, but the task has not been completed;
T2 time concurrent with a reading task, you can still read V0 version of the data;
T3 moment and complicated by a reading task, still does not block;

It can be seen multiple versions of data, through the "read the old version of the data" can greatly improve concurrency tasks.

Improve the concurrent evolution of ideas, in the case:

Ordinary lock, is essentially a serial execution
Read-write locks, you can achieve concurrent read
Multiple versions of data, you can achieve concurrent read and write

Well, corresponds to the InnoDB, specifically how to play it?

redo, undo, times 滚段

Before further explains how to use the InnoDB "read the old version of the data" concurrency greatly improve the task, it is necessary to introduce the next redo logs, undo logging, rollback ( ROLLBACK segment).

Why should redo log?

After the database transaction is committed, the updated data must be brushed onto the disk, in order to ensure the ACID properties. Disk random write performance is low, if every brush plate, will greatly affect the throughput of the database.

Optimization way is to modify the behavior of the first write to redo log (this time into a sequential write), and then regularly brush data to disk, this can greatly improve performance.

Architecture design approach here is that random write optimized for sequential writes, the idea is more important.

If at some point, the database crashes, not enough time to brush disk data in the database is restarted, it will redo redo logs in the content, to ensure that the transaction has been submitted to the impact on the data generated by the brush onto the disk.

Word, redo logs are used to protect, ACID properties of a committed transaction.

Why should undo log?

When the database uncommitted transaction, the transaction will be mirrored revised data (ie the old version before the amendment) stored in the undo log, when the transaction is rolled back, when Ben collapse or database, you can use undo log that the old version of the data, the revocation impact of the transaction on the database generated uncommitted.

For insert operations, undo log record new data PK (ROW_ID), delete rollback;
For delete / update operation, undo logging old data row, directly rollback recovery;
They were stored in a different buffer inside.

Word, undo logs are used to protect, not to commit the transaction will not affect the ACID properties database.

What is the rollback?

Undo log storage place is rollback.

MVCC undo logs and rollback segments and InnoDB are closely related, there is an example to explain unfold.

表：t(id PK, name);

Data:

1, shenjian

2, zhangsan

3, lysis

At this point there is no uncommitted transactions, so the rollback is empty.

Then starts a transaction:

start trx;
delete (1, shenjian);
update set(3, lisi) to (3, xxx);
insert (4, wangwu);

can be seen:

Before (1, shenjian) is deleted as the old version of the data into the rollback;
Before being modified (3, lisi) as the older version of the data into the rollback;
Data to be inserted, PK (4) into the rollback;

Next, if the transaction ROLLBACK , this time may be, by the rollback in the undo log roll assume the transaction commits , the rollback segment in undo log can be deleted.

can be seen:

Deleted old data restored;
Modified the old data also recovered;
Data to be inserted, deleted;

Transaction rollback is successful, all as before.

InnoDB storage engine is based on multi-version concurrency control

MVCC is to reduce by concurrent transactions, "read the old version of the data" lock conflicts, improve concurrency tasks.

key problem:

The old version of the data stored?
Store the old version of the data, whether or not there is a huge impact on MySQL and InnoDB original architecture?

By paving the way undo and rollback log above, these two issues is very good answer:

Previous versions of data are stored in the rollback in;
MySQL and InnoDB original architecture of the system has little impact;

InnoDB kernel, all the row data will increase three internal attributes:

DB_TRX_ID, 6 bytes, the last line of each record change its transaction ID;
DB_ROLL_PTR, 7 bytes, recording undo log pointer rollback;
DB_ROW_ID, 6 bytes, monotonically increasing line ID;

Why InnoDB able to do such a high concurrency?

Rollback segments in the data, in fact, is a snapshot of historical data (snapshot), these data are not modified, select can do anything concurrent reads them.

Snapshot read (the Read Snapshot) , this consistency is an unlocked read (Consistent Nonlocking Read), it is one of the core reasons for InnoDB concurrently so high.

Consistency here is the transaction to read data, either before the start of the transaction on existing data (of course, is another committed transaction generated), the transaction itself either insert or modify data.

Select a snapshot of what is read?

Unless Show Lock, ordinary snapshot of select statements are read, for example:

select * from t where id>2;

Show Lock here, refers to non-snapshot read:

select * from t where id>2 lock in share mode;
select * from t where id>2 for update;

to sum up

Common concurrency control methods to ensure data consistency lock, multiple versions of data;
Common lock serial, parallel read-write lock, multi-version read and write data in parallel;
redo logs to ensure a committed transaction ACID properties, the design idea is random write, sequential write increase concurrency by substitution;
undo log to roll back uncommitted transactions, where it is stored in the rollback;
MVCC is based on InnoDB storage engine, which uses undo logs are stored in the rollback in, that the old version of the data, improve concurrent;
The reason why high concurrency InnoDB, read snapshot unlocked;
InnoDB are all common select a snapshot reading;

Knowledge of this paper are based on MySQL5.6.