Начиная с версии MySQL 4.0.5, появилась возможность менять уровни изолирован­ности транзакций с помощью переменной TRANSACTION ISOLATION LEVEL. По умол­чанию MySQL устанавливает уровень изолированности REPEATABLE READ. Его можно отменить с помощью команды SET. 
Листинг 12.15.
mysql> SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.00 sec)
Текущее значение этой переменной определяется с помощью быстрого оператора SELECT.
Изменение уровня изолированности транзакций
По умолчанию значение переменной TRANSACTION ISOLATION LEVEL устанавли­вается для каждого сеанса отдельно, но ее можно задать и глобально для всех сеансов с помощью ключевого слова GLOBAL в командной строке SET.
Листинг 12.17.
mysql> SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.00 sec)
Но для выполнения этой операции требуется привилегия SUPER. Способ получения этой (и других) привилегии подробно описан в главе 14, "Безопасность, управление дос­тупом и привилегии". Это непосредственно касается системы управления доступом
MySQL.
Транзакции и производительность
Вследствие того, что при поддержке транзакции база данных должна работать в более напряженном режиме, чем база данных, транзакций не поддерживающая, т.к. ей необхо­димо изолировать сеансы различных пользователей друг от друга, вполне понятно, что это отражается на производительности системы. Удовлетворение других правил ACID, а особенно тех, которые направлены на обеспечение целостности баз данных при сбоях системы, для чего используются журналы транзакций, накладывает дополнительную на­грузку на системы, работающие с поддержкой транзакций. И MySQL не является ис­ключением из этого правила - при прочих равных условиях таблицы MyISAM, не под­держивающие работу транзакций, работают значительно быстрее таблиц типа InnoDB и BDB, которые транзакции поддерживают. (Большей частью это зависит от типа запроса и взаимовлияния запросов. Совмещение операций чтения и записи способствует ускорению работы таблиц InnoDB, а таблицы MyISAM выигрывают у InnoDB при сканировании таблиц и больших операциях DELETE.)
Можно сказать, что если у вас нет иного выбора, чем использовать таблицы, рабо­тающие с транзакциями, у вас остается небольшой маневр для того, чтобы транзакции не перегружали систему.
Используйте небольшие транзакции
Хорошо известный принцип KISS (Keep It Simple, Stupid!) вполне применим и в сложном мире транзакций, потому что MySQL использует блокировку на уровне строк для предотвращения одновременного чтения разными транзакциями одной и той же за­писи базы данных с большой вероятностью его разрушения. Механизм блокировки на уровне строк предотвращает доступ к строке более чем одной транзакции, что не только предохраняет данные от разрушения, но и приводит к тому, что другим транзакциям приходится ожидать завершения работы транзакции, осуществляющей блокировку. Таким образом, если транзакция небольшая, это время ожидания будет совершенно незаметным. Однако при работе с большими базами данных и большим количеством сложных транзакций, длительное время ожидания, пока другие транзакции снимут блокировку, может существенно повлиять на производительность всей системы.
По этой причине хорошим "тоном" считается сохранение размера транзакций не­большим и ускорение выполнения ими изменений, чтобы другие транзакции, ожидающие своей очереди, при этом не испытывали больших задержек. На прикладном уровне с этой целью разработаны две общие стратегии.
Запусти меня
При запуске можно установить стандартный уровень изолированности. Для этого при запуске сервера mysqld используется специальный аргумент---transaction-isolation.

■ Ввод данных пользователем должен осуществляться до команды START TRANSACTION. Очень часто неопытные разработчики запускают транзакцию еще до получения полного набора значений, необходимого для нее. Другие транзакции, запущенные в это же время должны ждать своей очереди до тех пор, пока пользователь не введет все необходимые данные, вследствие чего прикладной процесс не обработает их, а затем запросит дополнительные данные и т.д. В одно­пользовательской среде такие задержки не имеют никакого значения, т.к. при этом другие транзакции не получают доступ к базе данных. Однако в многопользова­тельских системах задержка, вызванная одной транзакцией, может привести к волновому эффекту для всех других транзакций, ожидающих своей очереди, вызвав тем самым существенную деградацию производительности всей системы.
■ Попробуйте разбить большие транзакции на маленькие и выполнить их независимо друг от друга. Это приведет к ускорению выполнения каждой транзакции, освобождая тем самым большие системные ресурсы, которые в противном случае обслуживали бы систему.