MySQL: уровни изоляции транзакций

[pokryshkin]

При чем тут MySQL, если это SQL-92?
Смысл «переводить» документацию, если любая книжка про БД, изданная за последние лет 20, в главе про транзакции содержит все тоже самое?

[max_mara]

Я с вами абсолютно согласен, но довольно часто дальше чтения мануалов из сети дело не заходит или ограничивается каким-то общим изданием типа "{Язык} для {уровня}".
Кто-то на эту «статью» посмотрит, увидит новые слова и у него уже отложится что-то в памяти.

[pokryshkin]

Хорошо, давайте сравним со статьей на википедии. Имхо, на википедии лучше.
Глядя на Вашу статью читатель еще и ошибок понаделает: у Вас «в заголовках» COMMITTED написано с одной буквой T, но это уже я так, просто чуть придираюсь.

[skyogre]

В этой статье хотя бы описывается, пусть и скудно, как ведёт себя сервер БД в каждом конкретном случае. В документации же, также как и в википедии, описывается какие проблемы решаются на каком уровне. Формализм какой-то… мне что, исходники SQL сервера вскрывать, чтобы разобраться во всём этом?

[StraNNikk]

Не согласен с автором статьи по следующим пунктам:

При чем внутри транзакции данные тоже будут еще не доступны.
Если рассмотреть транзакцию выше, то первый SELECT ничего не вернет, т.к. таблица у нас еще пустая и транзакция не подтверждена.

делаю:

mysql> SET SESSION tx_isolation='READ-COMMITTED';
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test;
+----+------+
| id | val  |
+----+------+
|  1 |    2 |
+----+------+
1 row in set (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test values (null, 3);
Query OK, 1 row affected (0.00 sec)

mysql> select * from test;
+----+------+
| id | val  |
+----+------+
|  1 |    2 |
|  2 |    3 |
+----+------+
2 rows in set (0.00 sec)

Внутри транзакции данные доступны в любой момент перед совершением COMMIT. Причем как в READ-COMMTITED, так и в REPEATABLE-READ.
Едем дальше:

Третий REPEATABLE READ
Этот уровень используется по умолчанию в MySQL. Отличается от второго тем, что вновь добавленные данные уже будут доступны внутри транзакции, но не будут доступны до подтверждения извне.
Здесь может возникнуть теоретическая проблема «фантомного чтения». Когда внутри одной транзакции происходит чтение данных, другая транзакция в этот момент вставляет новые данные, а первая транзакция снова читает те-же самые данные.

В MySQL проблема Phantom reads не актуальна. Подробнее см:
stackoverflow.com/questions/5444915/how-to-produce-phantom-reads
forums.mysql.com/read.php?97,189781,189781
dev.mysql.com/doc/refman/5.0/en/set-transaction.html#isolevel_repeatable-read
This is the default isolation level for InnoDB. For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read. This convention means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other.

[StraNNikk]

Неправильно выразился. Точнее проблема Phantom Reads при уровне изоляции REPEATABLE READ таки есть, но она не актуальна в случае приведенного в статье примера и не воспроизведется с обычной выборкой через SELECT. А вот в случае SELECT FOR UPDATE очень даже воспроизведется.

[medvedGrizli]

Второй READ COMMTITED
В данном случае прочитать данные возможно только после вызова COMMIT. При чем внутри транзакции данные тоже будут еще не доступны.

Пожалуйста, не вводите людей в заблуждение и исправьте текст статьи! Как говорил уважаемый StraNNikk, свои изменения всегда доступны внутри транзакции, до коммита.

[DavidRenoir]

по-моему, легендарная статья : ) одно время она была первой в выдаче поисковиков по теме уровней изолированности в Mysql, и потому смутила многие неокрепшие умы...
но как уже отметили много лет назад, в тексте есть критические ошибки в описании режима READ COMMITTED (не считая более мелких неточностей).