Изолированность
Изолированность предполагает, что все транзакции происходят в своем собственном пространстве, изолированном от других происходящих в системе транзакций, а результаты выполнения транзакций становятся видимыми только после полного ее завершения. Даже если сразу несколько транзакций происходят в такой системе одновременно, принцип изолированности гарантирует невидимость результатов транзакции до тех пор, пока эта транзакция не будет полностью завершена. Например, в прежнем примере с фондовой биржей изолированность предполагает, что транзакция между двумя маклерами будет независима от всех других транзакций на бирже и ее результат будет виден всем сразу, но только после ее завершения.
Это очень важно в том случае, когда система поддерживает одновременную работу многих пользователей и соединений (что справедливо и в случае с MySQL). Системы, не соответствующие этому фундаментальному принципу, могут испытывать разрушение данных, т.к. целостность каждого отдельного пространства очень скоро будет нарушена другими параллельно работающими и всегда конфликтующими между собой транзакциями. 
Конечно, в действительности единственный способ достичь - это обеспечить, чтобы в каждый момент времени к базе данных мог получить доступ только один пользователь. Но это нельзя назвать оптимальным решением при работе с такой многопользовательской реляционной СУБД, каковой является MySQL. В большинстве транзактивных систем для изоляции изменений, проделанных различными транзакциями, используется блокировка на страничном уровне или блокировка на уровне строк, что приводит к незначительным накладным расходам в производительности. Например, в MySQL дескриптор таблиц типа BDB для безопасной обработки множества одновременных транзакций использует блокировку на страничном уровне. В это же время дескриптор таблиц типа InnoDB использует более точную блокировку на уровне строк (см. во врезке "Блокировка", где вы найдете более подробную информацию об уровнях блокировки таблиц различного типа).
Живучесть
Живучесть, означает, что изменения, сделанные транзакцией, остаются в силе, даже если система после завершения транзакции и обновления всех регистрационных журналов завершила свою работу аварийно. Большинство современных реляционных СУБД обеспечивают живучесть данных с помощью журнала регистрации всех операций по из­менению данных в базе данных. Этот регистрационный журнал сохраняет информацию обо всех обновлениях, сделанных по таблицам, запросам, отчетам и т.д.
В случае полного отказа системы, разрушения среды хранения данных, или при пере­запуске, система с помощью информации из регистрационных журналов может восста­новиться до состояния последнего успешного обновления и отражать изменения, произ­веденные транзакциями в момент отказа системы. С точки зрения предыдущего примера продажи акций, живучесть означает, что если передача акций от маклера A к маклеру B была успешно завершена, система должна отображать это состояние, даже если после этого произошел полный отказ системы.
В MySQL принцип живучести реализован с помощью двоичного файла регистрации транзакций, в котором отслеживается изменения в системе во время выполнения тран­закций в случае сбоя аппаратной части или внезапной остановки системы, причем вос­становление утерянных данных является относительно простой задачей. Для этого во время рестарта системы используется последняя резервная копия в комбинации с реги­страционным журналом.
По умолчанию таблицы типа InnoDB на 100% являются живучими (другими словами, все транзакции, выполненные системой до ее остановки, в процессе восстановления гарантированно сохраняются на диске, и по ним может быть сделан откат). Таблицы My-ISAM имеют частичную живучесть - все изменения, выполненные в системе до послед­ней команды FLUSH TABLES, гарантированно сохраняются на диске.

Блокировка
MySQL поддерживает различные типы таблиц, которыми и определяются меха­низмы блокировки. Поэтому четкое представление о различных типах блокировок со­чень важно для создания среды, поддерживающей псевдотранзакции для типов таблиц MySQL, которые не поддерживают транзакций.
• Блокировка на уровне таблиц. Клиентом блокируется вся таблица для определенного типа доступа. В зависимости от типа блокировки, другие клиенты не смогут добавлять записи в таблицу и даже могут быть ограничены в чтении данных из них. 
• Блокировка на уровне страниц. MySQL блокирует определенное количество строк (это называется страницей). Заблокированные строки доступны только потоку, инициировавшему блокировку. Если другой поток попробует сделать запись в эти строки, он должен будет ожидать до тех пор, пока блокировка не будет снята. При этом принадлежащие другим страницам строки будут доступны для чтения.
• Блокировка на уровне строк. Блокировка на уровне строк предлагает более точное управление процессом блокировки, чем при блокировке таблиц и блокировке страниц. В этом случае блокируются только те строки, которые используются бло­кирующим потоком. Все другие строки таблицы остаются доступными для других потоков. В многопользовательских средах блокировка на уровне пользователя снижает конфликты между потоками, позволяя различным пользователям читать и даже производить запись одновременно в одну и ту же таблицу. Эта гибкость должна быть сбалансирована, однако справедливо и то, что эта гибкость дает и са­мую большую нагрузку из всех трех уровней блокировки.
В таблицах типа MylSAM поддерживается только одна блокировка - блокировка на уровне таблиц, которая дает выигрыш в производительности по сравнению со стра­ничной и построчной блокировкой в ситуации, когда количество операций чтения превышает количество операций записи. Для таблиц типа BDB поддерживается по­страничная блокировка, в то время как для таблиц типа InnoDB - автоматическая блокировка на уровне строк.
Подробнее о механизмах блокировок можно узнать в руководстве по MySQL по адресу http://www.mysql.com/doc/en/Locking_methods.html.