что такое транзакция
Что такое транзакция? Транзакция — это серия операций, выполняемых как единая логическая единица работы, которая, с точки зрения непрофессионала, представляет собой набор атомарных SQL-запросов. Поддержка транзакций в Mysql находится на уровне механизма хранения. Механизм хранения MyISAM не поддерживает транзакции, но поддерживает его InnoDB. Это наиболее фундаментальная причина, по которой механизм по умолчанию изменен с MyISAM на InnoDB после Mysql 5.5.5.
ACID-свойства транзакций
атомарность: как логическая единица работы выполнение всех операций в транзакции либо завершается успешно, либо завершается ошибкой.
Последовательность: база данных переходит из одного согласованного состояния в другое согласованное состояние без ущерба для целостности базы данных.
Изоляция: вообще говоря, изменения, сделанные одной транзакцией, не видны другим транзакциям, пока они не будут окончательно зафиксированы. Почему?Вообще говоря, чтобы улучшить параллелизм транзакций и создать различные уровни изоляции, пожалуйста, обратитесь к следующей главе за подробностями.
Долговечность: как только транзакция будет зафиксирована, сделанные ею изменения будут навсегда сохранены в базе данных, и измененные данные не будут потеряны, даже если система выйдет из строя.
уровень изоляции транзакций
Для максимально возможного параллелизма изоляция транзакций разделена на четыре уровня: незафиксированное чтение, зафиксированное чтение, повторяемое чтение и сериализуемое.. Пользователи могут выбирать различные уровни в соответствии со своими потребностями.
ЧИТАТЬ БЕЗ ЗАЯВЛЕНИЙ: Транзакция еще не зафиксирована, ее изменения видны другим транзакциям.
пример: Транзакция может читать транзакцию данных b, но не совершенные,приведет к грязным чтениям(Возможно, транзакция B завершится ошибкой после фиксации, а данные, прочитанные транзакцией A, будут грязными).
ПРОЧИТАТЬ СОВЕРШЕНО: после фиксации транзакции ее изменения могут быть видны только другим транзакциям. Уровень по умолчанию для большинства систем баз данных, но не для Mysql.
пример: транзакция A может только читать данные, измененные и зафиксированные транзакцией B,приведет к неповторяющимся чтениям(Выполнение двух запросов в транзакции A, один во время фиксации транзакции B и один после фиксации транзакции B, приведет к несогласованным результатам для двух чтений).
ПОВТОРЯЕМОЕ ЧТЕНИЕ: изменения незафиксированных транзакций не видны другим транзакциям, а результаты чтения одной и той же записи несколько раз во время транзакции согласуются.пример: транзакция A получает записи в определенном диапазоне несколько раз в процессе выполнения, и после фиксации транзакции B в этом диапазоне вставляется или удаляется N записей, и во время выполнения транзакции A будут возникать несоответствия в нескольких чтениях диапазона.фантомное чтение(Уровень Mysql по умолчанию, InnoDB решает проблему фантомного чтения через MVVC).
Сериализация (SERIALIZABLE): когда между двумя транзакциями возникает конфликт чтения-записи, база данных проходитБлокировка обеспечивает последовательное выполнение транзакций, решает все проблемы, упомянутые выше (грязные чтения, неповторяющиеся чтения, фантомные чтения). это самый высокий уровень изоляции изоляции.
Стол может более четко описать четыре уровня определения и возможных проблем:
Транзакции в Mysql
1. Автоматическая отправка транзакций
Mysql по умолчанию использует режим AUTOCOMMIT, то естьЕсли вы явно не начинаете транзакцию, каждый запрос рассматривается как операция фиксации транзакции.. Вы можете проверить, включена ли в mysql автоматическая фиксация, выполнив следующую команду:
mysql> show variables like 'AUTOCOMMIT';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | ON |
+---------------+-------+
1 row in set (0.01 sec)
--1 或者 ON 表示启用， 0 或者 OFF 表示禁用
mysql> SET AUTOCOMMIT = 0/1;
--以上命令可以打开和关闭自动提交
1. Отключите автофиксацию текущей сессии через set autocommit = 0. Если она должна действовать глобально, ее нужно изменить в конфигурационном файле.
2. После отключения автоматической фиксации все операторы DML пользователя будут находиться в одной и той же транзакции до тех пор, пока не встретится инструкция COMMIT или ROLLBACK для завершения транзакции.
Движущееся изображение, иллюстрирующее два вышеуказанных момента:
Конечно, пользователь может запустить транзакцию явно через start transaction или begin. ** Показанная открытая транзакция автоматически выполняет set autocommit = 0 и выполняет set autocommit = 1 после завершения транзакции фиксацией или откатом. ** Управляющие операторы для большего количества транзакций следующие:
START TRANSACTION | BEGIN： 显式地开启一个事务；
COMMIT：也可以使用 COMMIT WORK，不过二者是等价的。COMMIT 会提交事务，并使已对数据库进行的所有修改成为永久性的；
ROLLBACK：也可以使用 ROLLBACK WORK，不过二者是等价的。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改；
SAVEPOINT identifier：SAVEPOINT 允许在事务中创建一个保存点，一个事务中可以有多个 SAVEPOINT；
RELEASE SAVEPOINT identifier：删除一个事务的保存点，当没有指定的保存点时，执行该语句会抛出一个异常；
ROLLBACK TO identifier：把事务回滚到标记点；
SET TRANSACTION：用来设置事务的隔离级别。
2. Уровень изоляции транзакции
Самым популярным механизмом хранения для Mysql для поддержки транзакций является InnoDB, поэтому следующие настройки уровня изоляции Mysql основаны на InnoDB.
1. Просмотрите уровень изоляции на уровне системы и уровень изоляции на уровне сеанса механизма хранения InnoDB.Команды и результаты следующие:
mysql> select @@global.tx_isolation,@@tx_isolation;
+-----------------------+-----------------+
| @@global.tx_isolation | @@tx_isolation |
+-----------------------+-----------------+
| REPEATABLE-READ | REPEATABLE-READ |
+-----------------------+-----------------+
2. Установите уровень изоляции механизма хранения InnoDB:
Заявление:
set [ global | session ] transaction isolation level Read uncommitted | Read committed | Repeatable | Serializable;
Пример:
mysql> set session transaction isolation level Serializable;
Query OK, 0 rows affected (0.01 sec)
mysql> select @@global.tx_isolation,@@tx_isolation;
+-----------------------+----------------+
| @@global.tx_isolation | @@tx_isolation |
+-----------------------+----------------+
| REPEATABLE-READ | SERIALIZABLE |
+-----------------------+----------------+
1 row in set (0.00 sec)
3. Механизм транзакций MVCC
Двигатель хранения транзакций MySQL (InnoDB) использует MVCC (Multi-Version Concularention Control, Multi-верситель одновременный контроль) вместо производительности блокировки классов на уровне для улучшения одновременного чтения и записи. Принцип MVCC of InnoDB относительно прост. Это достигается за счет сохранения трех скрытых столбцов (номер версии идентификатора транзакции, номер версии строки, номер истечения срока действия строки »после каждой строки, а ниже приведенный ниже принцип работы MVCC:
INSERT:InnoDB сохраняет текущий номер версии системы как номер версии строки для каждой вновь вставленной строки.
UPDATE:Чтобы вставить новую строку, InnoDB сохраняет текущий номер версии системы в качестве номера версии строки и сохраняет текущий номер версии системы в исходной строке в качестве идентификатора удаления строки.
DELETE:InnoDB сохраняет текущий номер версии системы в качестве идентификатора удаления строки для каждой удаленной строки.
SELECT:InnoDB проверяет каждую строку на соответствие следующим двум условиям:
- InnoDB ищет только те строки данных, версия которых предшествует текущей версии транзакции (то есть номер системной версии строки меньше или равен номеру системной версии транзакции), что гарантирует, что строки, прочитанные транзакцией, уже существовали ранее. транзакция запущена, либо вставлена, либо изменена самой транзакцией.
- Удаленная версия строки либо не определена, либо больше номера версии текущей транзакции. Это гарантирует, что строки, прочитанные транзакцией, не будут удалены до начала транзакции.
В качестве результатов запроса могут быть возвращены только записи, соответствующие двум указанным выше условиям.
Операции INSERT/DELETE/UPDATE/SELECT в MVCC описаны ниже на более простом и понятном примере: Предположим, что в тестовой таблице есть два поля: имя и возраст; три поля скрытых столбцов MVCC называются transaction_id, create_version и delete_version.
insert
- версия_удаления не определена или больше, чем версия_удаления транзакции, в которой находится выбор.
- create_version меньше или равен create_version транзакции, в которой находится выбор.
На этом примере давайте посмотрим, почему MVCC может разрешать фантомные чтения при уровне изоляции REPEATABLE READ. Предположим, транзакция начинается после обновления и до удаления и заканчивается после удаления следующим образом:
start transaction; //假如事务 id = 2.5
select * from test; //执行时间在 update 之后 delete 之前
select * from test; //执行时间在 delete 之后
commit;
Если MVCC не используется, первый выбор * из теста может прочитать 1 запись, а второй — 0 записей, а записи, прочитанные несколькими запросами диапазона выбора в одной и той же транзакции, несовместимы, что является фантомным чтением. После использования MVVC записи, прочитанные двумя операторами выбора, одинаковы.
MVCC работает только при двух уровнях изоляции: REPEATABLE READ и READ COMMITTED. Два других уровня изоляции несовместимы с MVCC, поскольку READ UNCOMMITTED всегда считывает последнюю строку, а не строку, соответствующую текущей версии транзакции. SERIALIZABLE, с другой стороны, блокирует все прочитанные строки.
4. Реализация транзакций (журнал повторов/отмен)
Изоляция транзакций достигается с помощью блокировок или механизмов MVCC, а атомарность, устойчивость и согласованность достигаются с помощью журналов повторов/отмен. Журнал повторов называется журналом повторов и используется для обеспечения атомарности и надежности транзакции. Журнал отмены называется журналом отмены и используется для обеспечения согласованности транзакций.
1. журнал повторов
Базовые концепты
Журнал повторов используется для обеспечения устойчивости транзакций и состоит из следующих двух частей:
- Буфер журнала повторов (redo log buffer), в памяти, легко теряется.
- Файл журнала повторов, на диске, постоянный.
Файл журнала повторов записывается последовательно, и его не нужно читать во время работы базы данных, он будет читаться только тогда, когда база данных запускается для восстановления данных. Файл журнала повторов представляет собой физический журнал.Так называемый физический журнал означает, что содержимое журнала представляет собой команды, непосредственно управляющие физическими страницами. При переделывании соответствующая операция выполняется на физической странице.
Общий процесс
Блок-схема однократного обновления данных операции транзакции выглядит следующим образом:
-
Шаг 1: Сначала прочитайте исходные данные с диска в память и измените копию данных в памяти.
-
Шаг 2: Создайте журнал повторов и запишите его в буфер журнала повторов, в котором записывается измененное значение данных.
-
Шаг 3:когда необходимо, сбросить содержимое буфера журнала повторов в файл журнала повторов, добавив запись.
-
Шаг 4: Периодически сбрасывайте измененные данные из памяти на диск.
Наиболее важным из вышеперечисленного является третий шаг, на которомкогда необходимоБывают следующие ситуации:
- Когда транзакция зафиксирована (наиболее распространенный случай, перед фиксацией)
- Когда используется половина памяти в буфере журнала
- контрольная точка журнала
- Когда экземпляр выключается
- Когда бинлог переключается
- фоновая нить
написать стратегию
Любой, кто изучал операционную систему Linux, знает, что опция O_DIRECT не включается, когда данные в памяти записываются в файл на диске. Данные сначала записываются в файловый буфер операционной системы, а затем в какой-то момент сбрасываются на диск. Процесс выглядит следующим образом:
Когда транзакция зафиксирована, буфер журнала повторов записывается в файл журнала повторов.Чтобы гарантировать, что данные могут быть правильно синхронизированы с файлом на диске (а не просто записаны в файловый буфер), InndoDB по умолчанию вызывает fsync для выполнения операция записи. Производительность fsync относительно низкая. Конечно, это только случай по умолчанию InnoDB также предоставляет параметр innodb_flush_log_at_trx_commit для настройки стратегии сброса журнала повторов на диск со следующими тремя значениями:
- Когда установлено значение 1, fsync требуется для каждой отправки транзакции, что является самой безопасной конфигурацией, и транзакции не будут потеряны, даже если транзакция не работает;
- При значении 2 выполняется только операция записи при фиксации транзакции, и гарантируется запись в систему только буфера, поэтому при сбое экземпляра транзакция не будет потеряна, но при сбое транзакция может быть потеряна;
- Если установлено значение 0, фиксация транзакций не запускает повторную запись, а остается для фоновых потоков.раз в секундуТаким образом, сбой экземпляра приведет к потере транзакций в течение максимум одной секунды.
Следующий рисунок может быть использован для более интуитивно иллюстрирующих различные стратегии в различных значениях InnoDB_FLush_Log_at_trx_commit. Чем ближе операция на диске, тем ниже производительность и, конечно, чем выше надежность. Таким образом, производительность: 1
восстанавливаться
Операции восстановления предпринимаются при запуске механизма InnoDB независимо от того, была ли база данных нормально закрыта при последнем запуске базы данных. Вся операция восстановления имеет следующие характеристики:
- Восстановление выполняется из части журнала, начиная с контрольной точки.
- последовательное чтение иПараллельное приложениеЖурнал повторов.
- Применение журналов повторовидемпотент.
- Журналы повторов — это физические журналы, и восстановление происходит относительно быстро.
2. журнал отмены
Базовые концепты
- Журнал отмен используется для достижения согласованности транзакций, и InndoDB может повторять страницы через журнал повторов. Но иногда транзакцию нужно откатить, тогда требуется журнал отмены.
- Журнал отмены также можно использовать для помощи механизму InnoDB в реализации механизма MVCC.
- Журнал отмен является логическим журналом, при восстановлении он не восстанавливает непосредственно физические страницы, а логически восстанавливает базу данных в исходное состояние.
- Генерация журнала отмен также сопровождается генерацией журнала повторов.
написать время
Перед началом сделки процесс выглядит следующим образом:
В InnoDB журнал отмены разделен на журнал отмены вставки и журнал отмены обновления.
insert undo log
Журналы, созданные операциями вставки. В соответствии с изоляцией записи, вставленные вставкой, видны только этой транзакции, поэтому журналы, сгенерированные вставкой, могут быть удалены после фиксации транзакции.
update undo log
Журналы операций удаления и обновления. Согласно предыдущему механизму MVCC можно было знать, что эта часть записи может использоваться другими транзакциями, поэтому даже если транзакция зафиксируется, соответствующий журнал не может быть удален. Когда транзакция будет зафиксирована, она будет сохранена в списке журнала отмены, а окончательное удаление будет выполнено в потоке очистки.
3. Процесс записи журнала повторов и отмен
undo записывает журнал перед обновлением, чтобы выполнить откат. redo записывает журнал после обновления для повтора. Упрощенная версия процесса генерации журналов повторов и журналов отмен выглядит следующим образом, что может упростить понимание разницы между повторами и отменами.
假设有A，B两个数据，原值分别为 1, 2；现将A更新为10，B 更新为 20；undo log记录信息过程如下：
1. 事务开始
2. 记录 A = 1 到 undo log
3. 更新 A = 10
4. 记录 A = 10 到 redo log
5. 记录 B = 2 到 undo log
6. 更新 B = 20
7. 记录 B = 20 到 redo log
8. redo log 信息写入磁盘
9. 提交事务
Суммировать
Это может быть не так блестяще, как индексные транзакции, но транзакции также являются более важной частью базы данных. Много раз мы просто используем некоторые команды для выполнения транзакционных операций, и даже для этого нужна только аннотация в среде Spring. Тем не менее, нет необходимости понимать лежащий в основе этого принцип.Эта статья представляет собой исчерпывающий обзор транзакций наиболее часто используемой базы данных Mysql, надеясь помочь вам понять транзакции более систематически. Таким образом, вы можете свободно говорить, обсуждаете ли вы с коллегами или справляетесь с интервью.
Ссылаться на
- Высокая производительность Mysql (третье издание)
- Инсайдер технологии Mysql: механизм хранения InnoDB (второе издание)
- MySQL Engine поддерживает роуминг журнала повторов InnoDB
- Разберитесь с четырьмя уровнями изоляции транзакций MySQL за десять минут
- Анализ повторов и отмен в транзакциях MySQL
- Подробное объяснение использования и принципа MVCC в Mysql
- Синхронный ввод-вывод Linux: синхронизация, fsync и fdatasync