Understanding Innodb Transaction Isolation: "
The MySQL Innodb storage engine provides ACID compliance, the ‘I’ being isolation. There are four states defined in MySQL with the tx_isolation system variable, READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ and SERIALIZABLE.
Generally MySQL installations do not modify the default value of tx_isolation = REPEATABLE-READ, however I have seen with a number of clients the default value has been changed to READ-COMMITTED. When I attempt to identify the reason why, I have always received the same reason. Oracle uses a default transaction isolation of READ-COMMITTED. See how Oracle Manages Data Concurrency and Consistency for more information.
However, while the literal string is the same, the actual implementation of READ-COMMITTED in Oracle more closely represents the REPEATABLE-READ in MySQL.
The following demonstrates what you can expect to see between the operation of these two modes.
| REPEATABLE-READ |
|---|
| Session 1 | Session 2 |
|---|
DROP TABLE IF EXISTS transaction_test;
CREATE TABLE transaction_test(
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
val VARCHAR(20) NOT NULL,
created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY(id)
) ENGINE=InnoDB DEFAULT CHARSET latin1;
INSERT INTO transaction_test(val) VALUES ('a'),('b'),('c');
| |
SELECT @@global.tx_isolation, @@session.tx_isolation;
+-----------------------+------------------------+
| @@global.tx_isolation | @@session.tx_isolation |
+-----------------------+------------------------+
| REPEATABLE-READ | REPEATABLE-READ |
+-----------------------+------------------------+
START TRANSACTION;
SELECT * FROM transaction_test;
+----+-----+---------------------+
| id | val | created |
+----+-----+---------------------+
| 1 | a | 2009-09-21 00:19:43 |
| 2 | b | 2009-09-21 00:19:43 |
| 3 | c | 2009-09-21 00:19:43 |
+----+-----+---------------------+
SELECT SLEEP(20);
| |
|
START TRANSACTION;
INSERT INTO transaction_test(val) VALUES ('x'),('y'),('z');
SELECT * FROM transaction_test;
+----+-----------------+---------------------+
| id | val | created |
+----+-----------------+---------------------+
| 1 | a | 2009-09-21 00:19:43 |
| 2 | b | 2009-09-21 00:19:43 |
| 3 | c | 2009-09-21 00:19:43 |
| 4 | x | 2009-09-21 00:21:00 |
| 5 | y | 2009-09-21 00:21:00 |
| 6 | z | 2009-09-21 00:21:00 |
+----+-----------------+---------------------+
COMMIT;
|
INSERT INTO transaction_test(val) VALUES (@@session.tx_isolation);
SELECT * FROM transaction_test;
+----+-----------------+---------------------+
| id | val | created |
+----+-----------------+---------------------+
| 1 | a | 2009-09-21 00:19:43 |
| 2 | b | 2009-09-21 00:19:43 |
| 3 | c | 2009-09-21 00:19:43 |
| 7 | REPEATABLE-READ | 2009-09-21 00:21:01 |
+----+-----------------+---------------------+
COMMIT;
|
|
| READ-COMMITTED |
|---|
SET SESSION tx_isolation='READ-COMMITTED';
TRUNCATE TABLE transaction_test;
INSERT INTO transaction_test(val) VALUES ('a'),('b'),('c');
|
SELECT @@global.tx_isolation, @@session.tx_isolation;
+-----------------------+------------------------+
| @@global.tx_isolation | @@session.tx_isolation |
+-----------------------+------------------------+
| REPEATABLE-READ | READ-COMMITTED |
+-----------------------+------------------------+
START TRANSACTION;
SELECT * FROM transaction_test;
+----+-----+---------------------+
| id | val | created |
+----+-----+---------------------+
| 1 | a | 2009-09-23 22:49:44 |
| 2 | b | 2009-09-23 22:49:44 |
| 3 | c | 2009-09-23 22:49:44 |
+----+-----+---------------------+
SELECT SLEEP(20);
| |
|
START TRANSACTION;
INSERT INTO transaction_test(val) VALUES ('x'),('y'),('z');
SELECT * FROM transaction_test;
+----+-----+---------------------+
| id | val | created |
+----+-----+---------------------+
| 1 | a | 2009-09-23 22:49:44 |
| 2 | b | 2009-09-23 22:49:44 |
| 3 | c | 2009-09-23 22:49:44 |
| 4 | x | 2009-09-23 22:52:38 |
| 5 | y | 2009-09-23 22:52:38 |
| 6 | z | 2009-09-23 22:52:38 |
+----+-----+---------------------+
COMMIT;
|
INSERT INTO transaction_test(val) VALUES (@@session.tx_isolation);
SELECT * FROM transaction_test;
+----+----------------+---------------------+
| id | val | created |
+----+----------------+---------------------+
| 1 | a | 2009-09-23 22:49:44 |
| 2 | b | 2009-09-23 22:49:44 |
| 3 | c | 2009-09-23 22:49:44 |
| 4 | x | 2009-09-23 22:52:38 |
| 5 | y | 2009-09-23 22:52:38 |
| 6 | z | 2009-09-23 22:52:38 |
| 7 | READ-COMMITTED | 2009-09-23 22:56:10 |
+----+----------------+---------------------+
COMMIT;
|
|
As you can see, under READ-COMMITTED your result set can change during the transaction. However, how practical is this example in an actual application.
In what circumstances would you consider using READ-COMMITTED? Is there an improvement in locking contention that can lead to less deadlock contention? What is the overhead in other areas?
Harrison writes in My Favorite New Feature of MySQL 5.1: Less InnoDB Locking that best locking out of InnoDB in 5.1 will be with READ-COMMITTED. Note that as mentioned, the impact is a change in replication mode that may have a more dramatic effect.
Heikki Tuuri comments in Understanding InnoDB MVCC that using READ-COMMITTED should help in a specific locking issue.
I am still unclear of the specific benefits in general terms for all environments. Review of the The InnoDB Transaction Model and Locking and specifically Consistent Nonlocking Reads provides “With READ COMMITTED isolation level, each consistent read within a transaction sets and reads its own fresh snapshot” which indicates that for certain workloads the reduced locking is a benefit.
Every environment is different and ultimately the actual transaction statements will determine what options and benefits work best.
PlanetMySQL Voting:
Vote UP /
Vote DOWN"
Posts
No comments:
Post a Comment