8.5.2. Оптимизация InnoDB Управление транзакциями

Установка MySQL значения по умолчанию AUTOCOMMIT=1 может наложить ограничения производительности на занятый сервер базы данных. Где практичный, обертка несколько связанных операций DML в единственную транзакцию, выходя SET AUTOCOMMIT=0 или a START TRANSACTION оператор, сопровождаемый a COMMIT оператор после произведения всех изменений.

InnoDB должен сбросить журнал к диску в каждой фиксации транзакции если та транзакция, сделанная модификациями к базе данных. Когда каждое изменение сопровождается фиксацией (поскольку со значением по умолчанию автоматически фиксируют устанавливать), пропускная способность ввода-вывода устройства хранения помещает прописную букву в число потенциальных операций в секунду.

Альтернативно, для транзакций, которые состоят только из сингла SELECT оператор, включая AUTOCOMMIT помогает InnoDB распознать транзакции только для чтения и оптимизировать их. См. Раздел 14.2.4.2.3, "Оптимизация для Транзакций Только для чтения" для требований.

Избегите выполнять откаты после вставки, обновления, или удаления огромных чисел строк. Если большая транзакция замедляет производительность сервера, откатывая это может сделать проблему хуже, потенциально беря несколько раз столь же долго, чтобы выполнить как исходные операции DML. Уничтожение процесса базы данных не помогает, потому что откат запускается снова на запуске сервера.

Минимизировать шанс этого появления проблемы: увеличьте размер пула буферов так, чтобы все изменения DML могли кэшироваться, а не сразу записаны диску; набор innodb_change_buffering=all так, чтобы обновление и удалило операции, буферизуются в дополнение к вставкам; и рассмотрите издание COMMIT операторы периодически во время большой работы DML, возможно повреждая сингл удаляют или обновляют в многократные операторы, которые работают на меньших числах строк.

Чтобы избавиться от безудержного отката, как только это происходит, увеличьте пул буферов так, чтобы откат стал ограниченным ЦП и работал быстро, или уничтожьте сервер и перезапуск с innodb_force_recovery=3, как объяснено в Разделе 14.2.3.14," InnoDB Процесс восстановления".

Эта проблема, как ожидают, будет менее видной в MySQL 5.5 и, или в MySQL 5.1 с Плагином InnoDB, потому что настройка по умолчанию innodb_change_buffering=all позволяет обновление, и удалите операции, которые будут кэшироваться в памяти, делая их быстрее, чтобы выполнить во-первых, и также быстрее откатывать если нужно. Удостоверьтесь, что использовали эту установку параметра на серверах, которые обрабатывают продолжительные транзакции со многими, вставляет, обновляет, или удаляет.

Если можно предоставить потерю некоторых из последних фиксировавших транзакций, если катастрофический отказ происходит, можно установить innodb_flush_log_at_trx_commit параметр к 0. InnoDB попытки сбросить журнал однажды в секунду так или иначе, хотя сброс не гарантируется. Кроме того, установите значение innodb_support_xa к 0, то, который сократит количество диска, сбрасывает из-за синхронизации на дисковых данных и двоичном журнале.

Когда строки изменяются или удаляются, строки и связались, журналы отмены физически сразу не удаляются, или даже сразу после фиксаций транзакции. Старые данные сохраняются до транзакций, которые запускались ранее или одновременно заканчиваются, так, чтобы те транзакции могли получить доступ к предыдущему состоянию измененных или удаленных строк. Таким образом продолжительная транзакция может предотвратить InnoDB от чистки данных, которые были изменены различной транзакцией.

Когда строки изменяются или удаляются в пределах продолжительной транзакции, другие транзакции, используя READ COMMITTED и REPEATABLE READ уровни изоляции должны сделать больше работы, чтобы восстановить более старые данные, если они читают те те же самые строки.

Когда продолжительная транзакция изменяет таблицу, запросы против той таблицы от других транзакций не используют покрытие, индексируют метод. Запросы, которые обычно могли получать все столбцы результата от вторичного устройства, индексируют, вместо этого ищут соответствующие значения от табличных данных.

Если у вторичных индексных страниц, как находят, есть a PAGE_MAX_TRX_ID это слишком ново, или если записи во вторичном устройстве индексируют, удаляют - отмеченный, InnoDB возможно, должен искать записи, используя кластерный индекс.