Когда вы INSERT, UPDATE или DELETE строка:
Краткий обзор:
- Получить блок, содержащий строку (или блок, который должен содержать строку). 2. Вставить / обновить / удалить строку.
- Пометить блок как «грязный». Со временем он будет записан на диск.
- Поместите неуникальные изменения вторичного индекса в «буфер изменений»
Подробнее (об этих шагах):
- Чтобы найти блок 16 КБ, разверните дерево
PRIMARY KEY's BT. Если блока нет в buffer_pool (который расположен в RAM), извлеките его с диска. (Это может включать в себя удаление какого-либо другого блока из buffer_pool. - Скопируйте предыдущее значение (в случае обновления / удаления) в журнал отмены и подготовьте его для сброса на диск.
- Фоновая задача сбрасывает грязные страницы на диск. Если все идет гладко, «большая часть» buffer_pool содержит не грязные страницы, и вам «никогда» не придется ждать «свободного» блока в buffer_pool.
- Буфер изменений является своего рода «отложенной записью» для обновлений индекса. Он прозрачен. То есть последующие поиски индекса будут автоматически искать в буфере изменений и / или BTree индекса. Данные в CB в конечном итоге будут смешаны с реальный индекс BTree и в конечном итоге сбрасывается на диск.
UNIQUE ключей: все INSERTs и UPDATEs, которые изменяют столбцы уникального ключа, обязательно проверяют наличие дубликата ключа, а не через буфер изменений.
AUTO_INCREMENT выполняет некоторые другие специальные действия.
В зависимости от значений innodb_flush_log_at_trx_commit и innodb_doublewrite что-то может быть записано на диск в конце сделки. Они обрабатывают транзакции "atomi c" и "порванные страницы".
Репликация. Другие действия могут включать в себя запись и синхронизацию binlog, а также передачу данных на другие узлы в кластере.
Конструкция «оптимистическая» c в том, что она оптимизирована для COMMIT за счет ROLLBACK. После фиксации запускается процесс очистки копий, которые были сохранены в случае cra sh и отката. Откат является более сложным в том смысле, что он должен вернуть старые копии строк. (См. Также «список истории».)
Поиск по некоторым ключевым словам, которые я упомянул; читать некоторые другие веб-страницы; затем вернитесь с более конкретным c вопросом.
Commit
Давайте посмотрим на это с другой стороны. Каждая строка, в том числе еще не подтвержденные строки, которые были изменены / удалены, имеет «идентификатор транзакции». Все строки для данной транзакции имеют одинаковый идентификатор. Так что, даже если есть cra sh, InnoDB, знает, что нужно очистить. COMMIT и ROLLBACK должны быть 'atomi c'; Этому способствует запись одной записи на диск "говорит все". Единственный способ сделать это возможным - это идентификатор транзакции. Имейте в виду, что миллионы строк могут быть разбросаны по всему параметру buffer_pool, а также файлам данных и журналам, ожидающим фиксации / отката.
После фиксации / отката InnoDB может спокойно выполнять очистку. Например, до тех пор, пока UPDATE не будет зафиксировано или откатано, в каждой строке будет изменено две копии. Один из рядов должен быть удален - в конце концов. Между тем, эти две строки находятся в «списке истории». Любые другие транзакции выполняют поиск в списке истории, чтобы увидеть, какую строку им разрешено видеть - READ UNCOMMITTED = последняя строка, в которой не была зафиксирована / откатана; READ COMMITTED = последняя строка, в которой было зафиксировано / откатано; et c.
Если я правильно понимаю, журнал отмен является оптимизацией. Например, в DELETE «старые значения» строк копируются в журнал отмены, а строка фактически удаляется из данных BTree. Оптимизация здесь заключается в том, что журнал отмены записывается последовательно, в то время как BTree может включать в себя намного больше блоков, разбросанных по всему столу. Также обычная обработка блоков данных включает в себя их кэширование в buffer_pool. Для фиксации записи в журнале отмены отбрасываются. Для отката есть утомительное усилие использования журнала отмены для восстановления.
Да, список истории добавляет работу для всех других транзакций, затрагивающих ваши недавно измененные строки. Но он включает режимы изоляции транзакций и помогает в восстановлении после сбоев.