Обычно запросы MySQL выполняются независимо друг от друга, без учета пре­дыстории и того, что будет впоследствии. Так, например, полностью обеспечива­ется последовательность операторов INSERT или UPDATE независимо от корректности выполнения операторов цепочки, потому что MySQL рассматривает каждый запрос как отдельный законченный блок, никак не связанный с предыдущими и последующими запросами.
Чаще всего такой подход без учета состояний хорошо работает в приложениях малого и среднего размера, связанных с простой бизнес-логикой. Однако в более сложных си­туациях, где действия определяются последовательностью операторов SQL по принципу "все или ничего", этот подход не приемлем. Речь идет о ситуациях, когда не только по­следовательные запросы зависят друг от друга (и т.о. их нельзя выполнить в полной изо­ляции друг от друга), но и сбой при выполнении одного запроса из последовательности запросов означает, что выполнение всей последовательности должно быть отменено. При этом изменения, сделанные предыдущими запросами, должны быть отменены, а база данных должна быть возвращена в первоначальное состояние.
Так как модель, не учитывающая состояний (stateless model), рассматривает запросы независимо друг от друга, не имея информации об их предшественниках, она не годится для адекватной обработки в упомянутых ситуациях ("все или ничего"). Поэтому и была разработана альтернативная модель, позволяющая сгруппировать последовательность опе­раторов SQL в единый блок или транзакцию, которая бы удовлетворила этому требованию.
Такие коммерческие СУБД, как Oracle и Microsoft SQL Server, и некоммерческие СУБД, как PostgreSQL, поддерживают механизм транзакций. До недавнего времени MySQL не входил в этот список, однако начиная с примитивной реализации механизма транзакций, в версии 3.23 и существенно доработанной в версии 4.x, MySQL уже имеет такие типы таблиц, которые позволяют работать с транзакциями во многом таким же об­разом, как и другие коммерческие СУБД.
В этой главе детально рассматривается транзактная модель MySQL, объясняется ее суть, принципы ее работы и то, каким образом она может помочь в создании надежно ра­ботающих приложений. В этой главе также рассматриваются альтернативные подходы к реализации модели обработки транзакций. 
Что такое транзакция?
В контексте SQL транзакция предполагает наличие одного или нескольких операторов SQL, работающих как единый целостный блок. Каждый оператор SQL в таком блоке зависит от других, и блок является единым и неделимым. Если один из операторов не за­вершается успешно, будет сделан откат всего блока и все задействованные данные будут возвращены в состояние, которое они имели перед началом транзакции. Таким образом, говорят, что транзакция отработала успешно, если все операторы, входящие в нее, были успешно выполнены.
Примеры транзакции бесчисленны - банковские переводы, биржевые операции, реа­лизация услуг электронных магазинов, учет движения материальных ценностей и др. Этот список можно продолжать до бесконечности. Общее успешное завершение транзакции зависит от корректного выполнения нескольких независимых операций. Неуспешное завершение хотя бы одной из них должно отменить транзакцию и возвратить систему в состояние, в котором она была до начала выполнения транзакции.
Рассмотрим простой пример: допустим, что на фондовой бирже маклер A продает маклеру B 400 акций компании "ACME Corp." (см. рис. 12.1).
Где-то вдали от суеты торгового зала находится сложная база данных, отслеживающая все сделки, происходящие на этой фондовой бирже. В этой системе сделка вроде той, что была описана выше, считается завершенной только после того, как счет маклера A дебетуется на 400 акций компании ACME, а счет маклера B одновременно кредитуется этими же самыми акциями. Если один из этих шагов не срабатывает, в системе зависнет 400 "бесхозных" акций корпорации "ACME Corp.", что отнюдь не хорошо, и вы должны с этим согласиться.
Таким образом, передача 400 акций компании "ACME Corp." от маклера A маклеру B можно считать транзакцией - единым блоком, содержащим несколько операторов SQL (удалить 400 акций со счета маклера A и добавить 400 акций на счет маклера B, выполнить расчет комиссионных для обоих маклеров и сохранить все сделанные изменения). В соответствии с прежним определением транзакции, все эти операторы должны выпол­няться успешно. Если какой-либо из них завершится ошибкой, должен быть сделан откат, а система должна быть возвращена в ее прежнее стабильное состояние. Или же необходимо, чтобы некоторое время принадлежность 400 акций была неопределенной.
Или другой пример: зачисление нового служащего в состав компании (см. рис. 12.2). Процедура здесь должна состоять из трех основных шагов - создания записи о новом служащем в базе данных, содержащей информацию о служащих, вводе этого служащего в ведомость отдела и задания структуры записи о служащем. Если любой из перечисленных шагов не сработает, например, если отведенный для нового служащего идентификатор уже используется кем-то другим или значения, вводимые в систему учета, превышают максимальную длину, вам потребуется отменить все изменения, сделанные в системе до возникновения ошибки. При этом удаляются все следы создания неполных записей, для того чтобы впоследствии избежать возможных несоответствий и ошибочных вычислений.
Все три задачи составляют одну транзакцию. Ошибка выполнения одной из них должна привести к отмене всей транзакции, и система должна вернуться в исходное состояние.
Транзакции