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

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

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

Если данные на диске или в памяти становятся поврежденными, механизм проверки контрольных сумм уведомит вас о неверных данных перед их использованием. Переменная 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 ГБ.