Если сервер неожиданно завершит работу из-за проблемы с аппаратным или программным обеспечением, независимо от того, что происходило в базе данных в это время, после перезапуска базы данных ничего специального делать не нужно. Восстановление после сбоя автоматически завершит изменения, которые были подтверждены до момента сбоя, и отменит изменения, которые были в процессе, но не подтверждены, что позволит вам перезапустить и продолжить с того места, где вы остановились. См. Раздел 17.18.2, «Восстановление InnoDB».

Движок хранилища InnoDB поддерживает собственный буферный пул, который кеширует данные таблиц и индексов в оперативной памяти по мере доступа к ним. Часто используемые данные обрабатываются непосредственно из памяти. Этот кеш применим ко многим типам информации и ускоряет обработку. На выделенных серверах баз данных часто до 80% физической памяти назначается буферному пулу. См. Раздел 17.5.1, «Буферный пул».

Если вы разделили связанные данные на разные таблицы, вы можете настроить внешние ключи, которые обеспечивают целостность ссылок. См. Раздел 15.1.21.5, «Ограничения внешних ключей».

Если данные повреждаются на диске или в памяти, механизм проверки контрольных сумм оповестит вас о ложных данных перед их использованием. Переменная innodb_checksum_algorithm определяет алгоритм проверки контрольных сумм, используемый InnoDB.

При проектировании базы данных с соответствующими столбцами первичного ключа для каждой таблицы операции, связанные с этими столбцами, автоматически оптимизируются. Очень быстро ссылаться на столбцы первичного ключа в WHERE предложениях, ORDER BY предложениях, GROUP BY предложениях и операциях объединения. См. Раздел 17.6.2.1, «Кластерированные и вспомогательные индексы».

Вставки, обновления и удаления оптимизируются с помощью автоматического механизма, называемого буферизацией изменений. InnoDB не только позволяет одновременный чтение и запись в одну и ту же таблицу, но и кеширует измененные данные для оптимизации ввода-вывода на диск. См. Раздел 17.5.2, «Буфер изменений».

Преимущества производительности не ограничиваются большими таблицами с длительными запросами. Когда одни и те же строки из таблицы обращаются многократно, адаптивный индекс хэширования берет на себя ускорение этих обращений, как будто они выполняются из хэш-таблицы. См. Раздел 17.5.3, «Адаптивный индекс хэширования».

Вы можете сжимать таблицы и связанные с ними индексы. См. Раздел 17.9, «Сжатие таблиц и страниц InnoDB».

Вы можете зашифровать свои данные. См. Раздел 17.13, «Шифрование данных InnoDB в состоянии покоя».

Вы можете создавать и удалять индексы и выполнять другие операции DDL с гораздо меньшим влиянием на производительность и доступность. См. Раздел 17.12.1, «Онлайн-операции DDL».

Обрезка табличного пространства на основе файла очень быстра и может освободить место на диске для повторного использования операционной системой, а не только InnoDB. См. Раздел 17.6.3.2, «Пространства таблиц на основе файла».

Структура хранения данных для таблиц более эффективна для BLOB и длинных текстовых полей, с форматом строк DYNAMIC. См. Раздел 17.10, «Форматы строк InnoDB».

Вы можете отслеживать внутреннюю работу движка хранилища, обращаясь к таблицам INFORMATION_SCHEMA. См. Раздел 17.15, «Таблицы InnoDB INFORMATION_SCHEMA».

Вы можете отслеживать детали производительности движка хранилища, обращаясь к таблицам Performance Schema. См. Раздел 17.16, «Интеграция InnoDB с MySQL Performance Schema».

Вы можете смешивать InnoDB таблицы с таблицами других движков хранилища MySQL, даже в одном и том же операторе. Например, вы можете использовать операцию объединения для объединения данных из InnoDB и MEMORY таблиц в одном запросе.

InnoDB был разработан для эффективности использования ЦП и максимальной производительности при обработке больших объёмов данных.

Таблицы InnoDB могут обрабатывать большие объёмы данных, даже на операционных системах, где размер файла ограничен 2 ГБ.