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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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