Как было подчеркнуто ранее, наиболее важным свойством реляционных СУБД, под­держивающих работу с транзакциями, является возможность "изолировать" различные активные сеансы в каждый конкретный момент на сервере. В однопользовательской среде это свойство не играет существенной роли по вполне очевидной причине: там нечего изолировать, т.к. в этом случае в каждый момент времени активным бывает только один сеанс работы с базой данных. Однако в более сложных примерах из реальной жизни это утверждение вряд ли будет справедливым.
В многопользовательских средах в любой момент времени может быть активным од­новременно целое множество сеансов. Например, в примере с биржевыми сделками, весьма маловероятно, чтобы в какой-то промежуток времени свершалась только одна сделка. Гораздо вероятнее, что одновременно происходят сотни или тысячи сделок. В та­кой ситуации очень важно, чтобы СУБД изолировала транзакции таким образом, чтобы они не влияли друг на друга и в целом ничто не влияло на производительность СУБД. 
Чтобы лучше понять важность принципа изолированности представим себе ситуацию полного ее отсутствия. Тогда различные операторы SELECT не смогут выбирать данные в контексте одной транзакции, т.к. обрабатываемые данные могут быть модифицированы в этом промежутке другими транзакциями. Таким образом, полностью нарушается целостность системы, в результате чего доверять полученным результирующим наборам или использовать их для вычислений будет невозможно. Поэтому свойство изо­лированности обеспечивает определенную степень изоляции транзакций, гарантируя то, что приложение на протяжении всей транзакции "видит" только целостные данные.
В соответствии со спецификациями стандарта ANSI/ISO SQL, MySQL обеспечивает следующие четыре уровня изолированности:
■ SERIALIZABLE
■ REPEATABLE READ
■ READ COMMITTED
■ READ UNCOMMITTED
Эти уровни изолированности транзакций определяют, в какой степени выполняемая транзакция открыта для других транзакций, и они приведены в иерархическом порядке от самых безопасных уровней до наиболее проблемных. Уровнями изолированности можно манипулировать с помощью переменной TRANSACTION ISOLATION LEVEL, которая подробнее обсуждается в разделе "Изменение уровня изолированности транзакций".
Итак, рассмотрим подробнее каждый из уровней изолированности.
serializable
Уровень изолированности SERIALIZABLE обеспечивает максимальную изоляцию транзакций, разделяя параллельные транзакции, как если бы они выполнялись последо­вательно одна за другой. Это проиллюстрировано на рис. 12.4.
Уровни изолированности транзакций
Здесь маклер A продает 400 акций маклеру B. Для того чтобы выполнить эту тран­закцию, система должна уменьшить счет маклера A на 400 акций и положить эти же 400 акций на счет маклера B. Предположим, что эти маклеры начали торги, имея по 1000 ак­ций. После успешного завершения транзакции у маклера A будет 600 акций, а на счету маклера B уже будет 1400 акций.
В данном случае из-за того, что уровень изолированности является максимальным, вторая транзакция "увидит" изменения в счетах маклеров A и B только после того, как их транзакция закончит свое выполнение. Изменения в существующих строках или добав­ление новых строк во время транзакции видимы не будут, причем предполагается, что эта идеально. Однако за это придется заплатить определенную цену: если все транзакции будут осуществляться с таким уровнем изолированности, MySQL потеряет в производи­тельности, т.к. для сохранения изолированности различных транзакций в каждый момент времени необходимо большое количество системных ресурсов.
repeatable read
Для приложений, которые могут пожертвовать безопасностью за счет выигрыша в производительности, MySQL предлагает уровень изолированности REPEATABLE READ. На этом уровне транзакции не выполняются последовательно. Однако транзакция не сможет "увидеть" изменения, выполненные параллельно выполняющимися транзакциями, пока сама не будет завершена.
Вероятно, во многом этот уровень изолированности подобен уровню изолированности SERIALIZABLE. В целом это действительно так, но с одним существенным различием: в то время как транзакция не может "видеть" изменения во время своего выполнения, внесенные параллельно работающими транзакциями, она может "видеть" новые записи (которые были добавлены в базу данных другими транзакциями). Иногда это называют ложным чтением (phantom read) или ложной вставкой (phantom insert), т.к. речь идет о ситуации, когда транзакция добавляет новую запись в базу данных с помощью оператора INSERT. Другие выполняющиеся в это время транзакции могут неожиданно "увидеть" эту строку-призрак при выполнении оператора SELECT.
Затруднения могут возникнуть, если эти транзакции выполняют, скажем, расчеты или используют агрегатные функции по записям таблицы, т.к. неожиданное появление новой строки может привести к непредсказуемым, нарушающим целостность результатам.
В случае ложного чтения (см. рис. 12.5) вторая транзакция может "увидеть" новую строку, добавленную первой транзакцией, до выполнения ею команды COMMIT. Это по­влечет за собой неожиданное изменение в данных, просматриваемых второй транзакцией, в тот момент, когда она все еще выполняется: между временными точками t2 и t4, количество акций на счету маклера A станет равным 500 даже несмотря на то, что тран­закция, приведшая к такому изменению еще не завершена. Это изменение вызвано не­ожиданным появлением во время выполнения транзакции новой ложной строки.