Analysis & Answers
Most database systems (such as Oracle) use Read-Committed as the default isolation level, while MySQL chooses Repeatable-Read as its default isolation level.
If you don’t have basic knowledge of isolation levels, take a look first: Let’s talk about the four isolation levels of Mysql
Look at the summary table
| transaction isolation level | dirty read | non-repeatable read | Phantom reading |
|---|---|---|---|
| read uncommitted | yes | yes | yes |
| non-repeatable read | no | yes | yes |
| repeatable read | no | no | yes |
| Serialization | no | no | no |
Why does it use repeatable read as its default isolation level?
Let’s first look at the three recording modes of binlog logs and their respective advantages and disadvantages: MySQL’s default binlog recording mode is row.
In early versions of MySQL, binlog only had a recording mode of statement, and a fatal problem caused by this mode was that the master-slave data was inconsistent under the read-commit (RC) isolation level. In binlog, the logging rule is: log after transaction commit.
Let's look at a case under the RC isolation mechanism: Assume that the binlog recording mode is statement at this time. Then the order of recording binlog is: at t4, record the delete statement of the t1 table; at t6, record the update statement of the t table. After master-slave synchronization, the master synchronizes its own binlog to the slave. A problem encountered when the slave performs synchronization: the slave will first delete the contents of the t1 table, and then update the records of the t table. This will cause the master-slave Inconsistent.
Next, let’s look at the same case under the RR isolation mechanism: Under the RR isolation mechanism, the operation of transaction B is blocked, so the recording order of binlog in statement mode will not be reversed, causing master-slave data inconsistency.
The same case under the RR isolation mechanism: Under the RR isolation mechanism, the operation of transaction B is blocked, so the recording order of binlog in statement mode will not be reversed, causing master-slave data inconsistency.
Therefore, since the binlog in early MySQL versions only had statement mode, and the binlog recorded under the read-commit (RC) isolation level using statement mode would lead to master-slave data inconsistency, therefore, MySQL chose to use repeatable read (RR) as the default isolation. level to ensure master-slave replication data consistency.
Reflect & Expand
The reason why MySQL chooses the rereadable transaction isolation mechanism is because early binlog only supports statement format, and this format may lead to master-slave inconsistency under the read-commit isolation mechanism. The key to MySQL's reread isolation mechanism to solve the problem of phantom reading is the implementation of MVCC. The transaction ID and row version ID ensure the consistency and isolation of reading. In MySQL, multi-version concurrency control (MVCC) is used to avoid the problem of phantom reading. However, phantom reading can only be avoided when selecting. Phantom reading may still occur when selecting after updating.
Meow Interview Assistant: A one-stop solution to interview questions. You can search the WeChat applet [Meow Interview Assistant] or follow [Meow Interview Assistant] -> Interview Assistant to answer questions for free. If you have any good interview knowledge or skills, I look forward to sharing them with you!