Last month we started
looking at transactions
in MySQL, in particular with InnoDB tables. This month we look at the four
transaction isolation levels, again with InnoDB tables, and see how they affect
the usual locking transactional behavior.
Transaction Isolation Levels
A transaction isolation
level sets the default transactional behaviour. Our examples last month all
took the default setting. This month, we see how changing the transaction
isolation level leads to different results. As the name suggests, the setting
determines how isolated each transation is, or what kind of locks are
associated with queries inside a transaction. The four levels, in ascending
order of strictness, are:
-
READ
UNCOMMITTED: Barely transactional, this setting allows for so-called ‘dirty
reads’, where queries inside one transaction are affected by uncommitted
changes in another transaction. -
READ
COMMITTED: Committed updates are visible within another transaction. This means
identical queries within a transaction can return differing results. This is
the default in some DBMS’s. -
REPEATABLE READ:
The default isolation level for InnoDB tables. Within a transaction, all reads
are consistent. -
SERIALIZABLE:
Updates are not permitted in other transactions if a transaction has run an
ordinary SELECT query, i.e. queries are treated as if they had a LOCK IN SHARE
MODE, which we saw in action last month.
InnoDB
tables support all four SQL standard transaction isolation levels. Be careful
when converting code from other DBMS’s, as they do not all support all four
levels, nor do they all default to the same level.
-
SQL SERVER –
READ COMMITTED -
Oracle – READ
COMMITTED (supports only READ COMMITTED, SERIALIZABLE and the non-standard READ
ONLY) -
DB2 –
REPEATABLE READ (supports REPEATABLE READ, UNCOMMITTED READ and 2 non-standard
levels) -
PostgreSQL –
REPEATABLE READ (only supports REPEATABLE READ and SERIALIZABLE)
For those who have
skipped Part 1, we are using the following table to test with:
mysql> DESC t;
+——-+———+——+—–+———+——-+
| Field | Type | Null | Key | Default | Extra |
+——-+———+——+—–+———+——-+
| f | int(11) | YES | | NULL | |
+——-+———+——+—–+———+——-+
1 row in set (0.05 sec)
You can
create and populate it as follows:
mysql> CREATE TABLE t (f INT) TYPE = InnoDB;
Query OK, 0 rows affected (0.00 sec)mysql> INSERT INTO t values (1),(2),(3),(4),(55);
Query OK, 5 rows affected (0.00 sec)
If you have not made a
specific change to the transaction isolation level, it will be a repeatable
read. You can check this as follows:
mysql> SELECT @@tx_isolation;
+—————–+
| @@tx_isolation |
+—————–+
| REPEATABLE-READ |
+—————–+
1 row in set (0.00 sec)
Repeatable Reads
In this exercise, we
begin a transaction, and see if a committed insert from another transaction is
visible in the midst of the transaction.
Connection 1
mysql> BEGIN;
Query OK, 0 rows affected (0.05 sec)mysql> SELECT * FROM t;
+——+
| f |
+——+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
+——+
5 rows in set (0.00 sec)
Connection 2
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)mysql> INSERT INTO t VALUES(6);
Query OK, 1 row affected (0.00 sec)mysql> COMMIT;
Query OK, 0 rows affected (0.00 sec)mysql> SELECT * FROM t;
+——+
| f |
+——+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
+——+
6 rows in set (0.00 sec)
Remember that it does not
matter to the second connection that the SELECT statement was run after the
COMMIT. Within the transaction, the new record is immediately visible.
Connection 1:
mysql> SELECT * FROM t;
+——+
| f |
+——+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
+——+
5 rows in set (0.00 sec)mysql> COMMIT;
Query OK, 0 rows affected (0.00 sec)mysql> SELECT * FROM t;
+——+
| f |
+——+
| 1 |
| 2 |
| 3 |
| 4 |
| 55 |
| 6 |
+——+
6 rows in set (0.00 sec)
This is the essence of
the repeatable read. The SELECT query returns a consistent result within a
transaction, and new records added from another window during the transaction
are not immediately visible. For a result to be visible, both the updating transaction,
and any transactions that are already open, needs to be committed.
