ACID - это аббревиатура, обозначающая четыре ключевых свойства систем обработки транзакций: атомарность, согласованность, изолированность и долговечность. Эти характеристики являются основополагающими для обеспечения надежности и защиты данных в базах данных.
ACID
Атомарность. Транзакция воспринимается как единое целое, и ее выполнение подразумевает, что или все действия выполняются успешно, или не выполняется ни одно. Это означает, что не может быть ситуации, когда некоторые изменения применяются, а некоторые - нет. Таким образом, транзакция либо завершается полностью, либо откатывается.
Согласованность. Каждый раз, когда транзакция завершается, база данных должна сохранять целостность, переходя из одного валидного состояния в другое. Например, если в одном из этапов транзакции происходит сбой, то делать выводы о наличии неполных данных нельзя - все изменения должны быть отменены, чтобы избежать появления несогласованных данных.
Изолированность. Результаты транзакции, пока она не завершена, должны быть невидимы для других транзакций. Это гарантирует, что операции, выполняемые одновременно, не повлияют на каждую другую. Например, если вычисления по остаткам на счетах запускаются между двумя операциями транзакции, они не должны учитывать изменения, которые еще не зафиксированы.
Долговечность. После успешного завершения транзакции её изменения становятся постоянными и должны быть сохранены, чтобы обеспечить защищенность данных в случае сбоя системы. Однако, несмотря на это свойство, долговечность нельзя считать абсолютной, так как всегда существует риск потери данных. Тем не менее, различные стратегии резервирования и восстановления данных могут предоставить различные уровни защиты.
ACID транзакции и их гарантии, особенно в контексте подсистемы InnoDB, представляют собой одну из самых сильных и надежных функций MySQL. Хотя их использование может влиять на производительность, правильная реализация этих принципов позволяет значительно упростить бизнес-логику на уровне приложений, освободив разработчиков от необходимости управлять сложными сценариями обработки данных.
Уровни изоляции
Изоляция транзакций — это более многогранное понятие, чем было описано выше. Стандарт ANSI SQL определяет четыре уровня изоляции. Цель данного стандарта — установить правила, по которым изменения становятся видимыми или невидимыми как внутри, так и вне транзакции. Более низкие уровни изоляции, как правило, позволяют большую степень конкурентного доступа и предполагают меньшие накладные расходы. Различные системы управления базами данных могут реализовать эти уровни по-своему, однако в целом они приближаются к данным правилам.
READ UNCOMMITTED (Незавершенное чтение). На уровне изоляции READ UNCOMMITTED транзакции могут видеть результаты незавершенных транзакций. Этот уровень редко применяется на практике, поскольку его производительность лишь незначительно лучше, чем у других уровней, обладающих множеством преимуществ. Чтение незафиксированных данных также известно как черновое или «грязное» чтение (dirty read).
READ COMMITTED (Подтвержденное чтение). Уровень изоляции по умолчанию в большинстве систем управления базами данных (за исключением MySQL) — READ COMMITTED. Он соответствует простому определению изоляции, приведенному ранее: транзакция будет продолжать "видеть" изменения, которые к моменту её начала были подтверждены другими транзакциями, а внесенные ею изменения останутся невидимыми для остальных транзакций до тех пор, пока текущая транзакция не будет завершена. Этот уровень по-прежнему допускает так называемое неповторяющееся чтение (nonrepeatable read), что означает, что вы можете выполнить одну и ту же операцию дважды и увидеть различные данные.
REPEATABLE READ (Повторяемое чтение) позволяет решить проблемы, возникающие на уровне READ UNCOMMITTED. Он гарантирует, что любые строки, прочитанные транзакцией, будут оставаться неизменными при следующем чтении в рамках одной и той же транзакции, однако теоретически по-прежнему допускает другую сложную проблему, известную как фантомное чтение (phantom reads). Проще говоря, фантомное чтение может произойти, когда вы выбираете определенный диапазон строк, затем другая транзакция добавляет новую строку в этот диапазон, после чего вы снова выбираете тот же диапазон. В результате вы увидите новую фантомную строку. InnoDB и XtraDB решают проблему фантомного чтения с помощью многоверсионного контроля конкурентного доступа (multiversion concurrency control). Уровень изоляции REPEATABLE READ установлен в MySQL по умолчанию.
SERIALIZABLE (Сериализуемость). Самый высокий уровень изоляции, SERIALIZABLE, разрешает проблему фантомного чтения, заставляя транзакции выполняться в таком порядке, который исключает возможность конфликта. В результате SERIALIZABLE блокирует каждую строку, которую она читает. На этом уровне могут возникнуть многочисленные тайм-ауты и конфликты из-за блокировок. Этот уровень редко используется на практике, но требования вашего приложения могут заставить вас использовать его, принимая на себя меньшую степень конкурентного доступа, но обеспечивая стабильность данных.
По мотивам источника: "MySQL по максимуму" 4-е издание, Ботрос С., Тинли Дж.
Про изолированность с картинками: https://blog.arbinada.com/ru/category/00619.html
Статья на Хабре про изолированность: https://habr.com/ru/articles/857486/
Про ACID и его базовую необходимость: https://habr.com/ru/companies/alfa/articles/812417/