7.5.8.6 Пример работы согласованного чтения в InnoDB

При выполнении согласованного чтения (т.е. обычного оператора SELECT) InnoDB определяет для транзакции момент времени, по состоянию на который запросу будет предоставляться информация из базы данных. Таким образом, если транзакция удаляет строку и фиксирует это изменение после назначенного момента времени, то вы не увидите, что строка была удалена. Это справедливо также для вставок и обновлений.

Чтобы такой момент времени ``передвинуть вперед'', нужно зафиксировать транзакцию, а затем выполнить новую команду SELECT.

Это называется многовариантным контролем совпадений.

		 Пользователь A 	  Пользователь B

		SET AUTOCOMMIT=0;	SET AUTOCOMMIT=0;

время
| 		SELECT * FROM t;
|		пустой набор данных
|					INSERT INTO t VALUES (1, 2);
|
v 		SELECT * FROM t;
		пустой набор данных
					COMMIT;
		SELECT * FROM t;
		пустой набор данных;

		COMMIT;

		SELECT * FROM t;
		---------------------
		| 1 | 2 |
		---------------------

Таким образом, пользователь A увидит строку, вставленную пользователем B только после того, как B зафиксирует вставку, и A зафиксирует свою собственную транзакцию, чтобы момент времени передвинулся на позицию, находящуюся после фиксации, произведенной пользователем B.

Чтобы увидеть ``самое свежее'' состояние базы данных, необходимо использовать чтение с блокировкой:

SELECT * FROM t LOCK IN SHARE MODE;

User Comments

COMMIT after SELECT is not needed for user A since
SELECT statement must always return the last
consistent snapshot of database (WITHOUT LOCK
ROW COMMAND) considering
previously commited changes from all other users.
That way you can improve much better locking
functionality, and leave users out of intensive need
for explicite locking !

What you said is Oracle way which is
"statement level"
read consistency by default. MySQL seems use
"Transaction
level" read consistency, a session only see data
commited before transaction began. In Oracle, if
usea A issues "set transaction read only", Oracle
will use "Transaction level"
read consistency, and the behavior will be same
to MySQL
one.

Add your own comment.