В предыдущей статье был затронут небольшой вопрос, когда устанавливается непротиворечивое представление транзакций базы данных?
Этот вопрос все еще относительно важен. Если мы не поймем его, это может повлиять на результаты наших экспериментов и сделать неправильные выводы. Поэтому сегодня Сун Гэ кратко расскажет вам об этой теме.
1. Демонстрация ошибок
Позвольте мне сначала продемонстрировать вам ошибку.
Открываем два сессионных окна, по умолчанию уровень изоляции повторяемое чтение, давайте посмотрим:
Сначала просмотрите текущую пользовательскую таблицу в сеансе A и откройте транзакцию после просмотра:
Вы можете видеть, что текущий возраст равен 101 году.
Затем измените возраст в сеансе B:
Видно, что сеанс B был успешно изменен.
Затем вернитесь к записи запроса сеанса A:
Как видите, запись сеанса А также изменилась. Полный процесс тестирования выглядит следующим образом:
А как насчет повторяемого чтения?
Само собой разумеется, что повторяемое чтение означает, что операции других транзакций с данными не влияют на текущую транзакцию, но вышеприведенный случай, кажется, отличается от повторяемого чтения, которое мы понимаем.
2. Анализ
Не знаю, ребята, помните ли вы еще особенности повторяемого чтения:
- Пользователь выполняет один и тот же оператор SELECT несколько раз в другой транзакции, и результат всегда один и тот же.
С этой точки зрения, в первом подразделе нет проблем, потому что мы выполняем оператор SELECT много раз в сеансе A, и результаты одинаковы, а возраст равен 102.
Но что нас озадачивает, так это то, что транзакция сеанса B явно открыта, но мы читаем модификацию B в сеансе A, что кажется неуместным.
Вот вопрос, когда устанавливается непротиворечивое представление о сделке?
На самом деле мы выполняемОператор begin не является реальной отправной точкой транзакции.. После выполнения start,Затем выполняется первый SQL, транзакция действительно запускается.
Немного изменим случай в первом подразделе:
В сеансе A после открытия транзакции немедленно выполните оператор SELECT, а затем перейдите в сеанс B, чтобы внести изменения. После завершения изменения вернитесь в сеанс A, чтобы продолжить запрос. В это время обнаружено, что модификация в B не видна A. Это Результаты также соответствуютПользователь выполняет один и тот же оператор SELECT несколько раз в другой транзакции, и результат всегда один и тот же..
Если мы хотим начать транзакцию сразу после выполнения begin, мы можем сделать это следующим образом:
start transaction with consistent snapshot;
После выполнения этого SQL транзакция начинается немедленно.
Далее, возвращаясь к случаю в первом подразделе, изменим команду для запуска транзакции:
В этот момент запрос транзакции в сеансе A не увидит изменения в сеансе B.
3. Резюме
Ну и небольшой кейс, надеюсь друзья не ошибутся при проведении опытов. В этой статье используется концепция, называемая представлением согласованности. Если вы не знакомы с ней, вы можете обратиться к предыдущей статье.