Какого движка нет в mysql

Chapter 16 Alternative Storage Engines

Storage engines are MySQL components that handle the SQL operations for different table types. InnoDB is the default and most general-purpose storage engine, and Oracle recommends using it for tables except for specialized use cases. (The CREATE TABLE statement in MySQL 8.0 creates InnoDB tables by default.)

MySQL Server uses a pluggable storage engine architecture that enables storage engines to be loaded into and unloaded from a running MySQL server.

To determine which storage engines your server supports, use the SHOW ENGINES statement. The value in the Support column indicates whether an engine can be used. A value of YES , NO , or DEFAULT indicates that an engine is available, not available, or available and currently set as the default storage engine.

This chapter covers use cases for special-purpose MySQL storage engines. It does not cover the default InnoDB storage engine or the NDB storage engine which are covered in Chapter 15, The InnoDB Storage Engine and Chapter 23, MySQL NDB Cluster 8.0. For advanced users, it also contains a description of the pluggable storage engine architecture (see Section 16.11, “Overview of MySQL Storage Engine Architecture”).

For information about features offered in commercial MySQL Server binaries, see MySQL Editions, on the MySQL website. The storage engines available might depend on which edition of MySQL you are using.

For answers to commonly asked questions about MySQL storage engines, see Section A.2, “MySQL 8.0 FAQ: Storage Engines”.

MySQL 8.0 Supported Storage Engines

InnoDB : The default storage engine in MySQL 8.0. InnoDB is a transaction-safe (ACID compliant) storage engine for MySQL that has commit, rollback, and crash-recovery capabilities to protect user data. InnoDB row-level locking (without escalation to coarser granularity locks) and Oracle-style consistent nonlocking reads increase multi-user concurrency and performance. InnoDB stores user data in clustered indexes to reduce I/O for common queries based on primary keys. To maintain data integrity, InnoDB also supports FOREIGN KEY referential-integrity constraints. For more information about InnoDB , see Chapter 15, The InnoDB Storage Engine.

MyISAM : These tables have a small footprint. Table-level locking limits the performance in read/write workloads, so it is often used in read-only or read-mostly workloads in Web and data warehousing configurations.

Memory : Stores all data in RAM, for fast access in environments that require quick lookups of non-critical data. This engine was formerly known as the HEAP engine. Its use cases are decreasing; InnoDB with its buffer pool memory area provides a general-purpose and durable way to keep most or all data in memory, and NDBCLUSTER provides fast key-value lookups for huge distributed data sets.

CSV : Its tables are really text files with comma-separated values. CSV tables let you import or dump data in CSV format, to exchange data with scripts and applications that read and write that same format. Because CSV tables are not indexed, you typically keep the data in InnoDB tables during normal operation, and only use CSV tables during the import or export stage.

Archive : These compact, unindexed tables are intended for storing and retrieving large amounts of seldom-referenced historical, archived, or security audit information.

Blackhole : The Blackhole storage engine accepts but does not store data, similar to the Unix /dev/null device. Queries always return an empty set. These tables can be used in replication configurations where DML statements are sent to replica servers, but the source server does not keep its own copy of the data.

NDB (also known as NDBCLUSTER ): This clustered database engine is particularly suited for applications that require the highest possible degree of uptime and availability.

Merge : Enables a MySQL DBA or developer to logically group a series of identical MyISAM tables and reference them as one object. Good for VLDB environments such as data warehousing.

Federated : Offers the ability to link separate MySQL servers to create one logical database from many physical servers. Very good for distributed or data mart environments.

Example : This engine serves as an example in the MySQL source code that illustrates how to begin writing new storage engines. It is primarily of interest to developers. The storage engine is a “ stub ” that does nothing. You can create tables with this engine, but no data can be stored in them or retrieved from them.

You are not restricted to using the same storage engine for an entire server or schema. You can specify the storage engine for any table. For example, an application might use mostly InnoDB tables, with one CSV table for exporting data to a spreadsheet and a few MEMORY tables for temporary workspaces.

Choosing a Storage Engine

The various storage engines provided with MySQL are designed with different use cases in mind. The following table provides an overview of some storage engines provided with MySQL, with clarifying notes following the table.

Table 16.1 Storage Engines Feature Summary

Feature	MyISAM	Memory	InnoDB	Archive	NDB
B-tree indexes	Yes	Yes	Yes	No	No
Backup/point-in-time recovery (note 1)	Yes	Yes	Yes	Yes	Yes
Cluster database support	No	No	No	No	Yes
Clustered indexes	No	No	Yes	No	No
Compressed data	Yes (note 2)	No	Yes	Yes	No
Data caches	No	N/A	Yes	No	Yes
Encrypted data	Yes (note 3)	Yes (note 3)	Yes (note 4)	Yes (note 3)	Yes (note 3)
Foreign key support	No	No	Yes	No	Yes (note 5)
Full-text search indexes	Yes	No	Yes (note 6)	No	No
Geospatial data type support	Yes	No	Yes	Yes	Yes
Geospatial indexing support	Yes	No	Yes (note 7)	No	No
Hash indexes	No	Yes	No (note 8)	No	Yes
Index caches	Yes	N/A	Yes	No	Yes
Locking granularity	Table	Table	Row	Row	Row
MVCC	No	No	Yes	No	No
Replication support (note 1)	Yes	Limited (note 9)	Yes	Yes	Yes
Storage limits	256TB	RAM	64TB	None	384EB
T-tree indexes	No	No	No	No	Yes
Transactions	No	No	Yes	No	Yes
Update statistics for data dictionary	Yes	Yes	Yes	Yes	Yes

Notes:

1. Implemented in the server, rather than in the storage engine.

2. Compressed MyISAM tables are supported only when using the compressed row format. Tables using the compressed row format with MyISAM are read only.

3. Implemented in the server via encryption functions.

4. Implemented in the server via encryption functions; In MySQL 5.7 and later, data-at-rest encryption is supported.

5. Support for foreign keys is available in MySQL Cluster NDB 7.3 and later.

6. Support for FULLTEXT indexes is available in MySQL 5.6 and later.

7. Support for geospatial indexing is available in MySQL 5.7 and later.

8. InnoDB utilizes hash indexes internally for its Adaptive Hash Index feature.

MySQL Storage Engines

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

Версия: MySQL 5.6

Системы хранения MySQL

Это механизм хранения по умолчанию для MySQL 5.5 и выше. Он предоставляет безопасные транзакции (ACID-совместимые) таблицы, поддерживает ограничения ссылочной целостности FOREIGN KEY. Он поддерживает функции фиксации, отката и восстановления после сбоя для защиты данных. Он также поддерживает блокировку на уровне строк. Это «согласованное чтение без блокировки» повышает производительность при использовании в многопользовательской среде. Он хранит данные в кластерных индексах, что уменьшает количество операций ввода-вывода для запросов на основе первичных ключей.

Другие темы:

Список модулей хранения, поддерживаемых вашей установкой MySQL

Следующая команда отображает информацию о состоянии механизмов хранения сервера.

Настройка механизма хранения

В CREATE TABLE STATEMENT вы можете добавить опцию ENGINE table, чтобы упомянуть механизм хранения. Смотрите следующие операторы CREATE TABLE, где использовались разные движки:

В MySQL 5.6 движком по умолчанию является InnoDB. Движок хранилища по умолчанию используется, если вы не упомянули имя другого движка в опции ENGINE. Вы можете указать механизм по умолчанию, используя опцию запуска сервера —default-storage-engine (формат командной строки) или установив параметр default-storage-engine в файле конфигурации my.cnf.

Вы можете установить механизм хранения по умолчанию для текущего сеанса, установив переменную default_storage_engine с помощью команды set.

Если вы хотите преобразовать таблицу из одного механизма хранения в другой, используйте инструкцию ALTER TABLE. Смотрите следующее утверждение:

Чтобы сохранить определения таблиц и столбцов для новой таблицы, MySQL всегда создает файл .frm. В зависимости от механизма хранения индекс и данные таблицы могут храниться в одном или нескольких других файлах. Сервер создает файл .frm выше уровня механизма хранения.

MySQL: механизм хранения InnoDB

InnoDB — это механизм хранения для MySQL, который сочетает в себе высокую надежность и высокую производительность. Начиная с MySQL 5.5 и выше, это механизм хранения по умолчанию.

Особенности движка хранения InnoDB:

Пределы хранения	64TB	операции	да	Блокировка детализации	Строка
MVCC (Multiversion параллельный контроль)	да	Поддержка типов геопространственных данных	да	Поддержка геопространственной индексации	нет
B-древовидные индексы	да	T-дерево индексов	нет	Хеш-индексы	нет
Индексы полнотекстового поиска	да	Кластерные индексы	да	Кэши данных	да
Индексные кеши	да	Сжатые данные	да	Зашифрованные данные	да
Поддержка базы данных кластера	нет	Поддержка репликации	да	Поддержка внешнего ключа	да
Резервное копирование / восстановление на момент времени	да	Поддержка кеша запросов	да	Обновить статистику для словаря данных	да

Преимущества хранилища InnoDB

• InnoDB имеет максимальную производительность при обработке больших объемов данных.
• Его операции DML (добавление, обновление и удаление данных) совместимы с моделью ACID (атомарной, согласованной, изолированной и надежной), с транзакциями, поддерживающими фиксацию, откат и восстановление после сбоя для защиты пользовательских данных.
• Система блокировки на уровне строк (блокировки размещаются на отдельных записях (строках)) повышает многопользовательский параллелизм и производительность. Все блокировки InnoDB, удерживаемые транзакцией, снимаются при фиксации или отмене транзакции.
• Таблицы InnoDB располагают ваши данные на диске для оптимизации запросов на основе первичных ключей.
• InnoDB поддерживает ограничения FOREIGN KEY для сохранения целостности данных. Поэтому вставки, обновления и удаления проверяются, чтобы убедиться, что они не приводят к несоответствиям между разными таблицами.
• В одном выражении можно смешивать таблицы InnoDB с таблицами из других механизмов хранения MySQL. Например, вы можете использовать операцию соединения для объединения данных из таблиц InnoDB и MEMORY в одном запросе.

Создание таблиц InnoDB:
Используйте оператор CREATE TABLE, чтобы создать таблицу InnoDB без каких-либо специальных предложений. Начиная с MySQL 5.5, это стандартный механизм хранения MySQL. В MySQL 5.6 при выполнении оператора CREATE TABLE без предложения ENGINE = создается таблица InnoDB. Вот пример:

Следующий оператор SHOW TABLE STATUS показывает свойства таблиц (принадлежит базе данных «tutorial»).

Обработка AUTO_INCREMENT в InnoDB :

InnoDB предоставляет метод, который улучшает масштабируемость и производительность операторов SQL, которые вставляют строки в таблицы со столбцами AUTO_INCREMENT. Чтобы использовать механизм AUTO_INCREMENT с таблицей InnoDB, столбец AUTO_INCREMENT (в данном случае col1) должен быть определен как часть индекса. Смотрите следующий пример:

Обработка ограничений FOREIGN KEY в InnoDB :

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

• InnoDB позволяет внешнему ключу ссылаться на любой столбец индекса или группу столбцов. Однако в ссылочной таблице должен быть индекс, в котором указанные столбцы перечислены как первые столбцы в том же порядке.
• InnoDB в настоящее время не поддерживает внешние ключи для таблиц с пользовательским разделением. Это означает, что ни одна разделенная пользователем таблица InnoDB не может содержать ссылки на внешние ключи или столбцы, на которые ссылаются внешние ключи.
• InnoDB позволяет ограничению внешнего ключа ссылаться на неуникальный ключ. Это расширение InnoDB для стандартного SQL.

Ограничение: таблица InnoDB :

• В таблице допускается максимум 1017 столбцов (в MySQL 5.6.9 по сравнению с более ранним пределом 1000).
• В таблице допускается не более 64 вторичных индексов. Вторичные индексы — это тип индекса InnoDB, который представляет собой подмножество столбцов таблицы.
• По умолчанию ключ индекса для индекса из одного столбца может содержать до 767 байтов. То же ограничение длины применяется к любому префиксу ключа индекса.
• Внутренняя максимальная длина ключа InnoDB составляет 3500 байт, но сам MySQL ограничивает это до 3072 байт (объединенный индексный ключ в многостолбцовом индексе).
• Максимальная длина строки, за исключением столбцов переменной длины (VARBINARY, VARCHAR, BLOB и TEXT), составляет около 8000 байтов при размере страницы по умолчанию 16 КБ.
• Внутренне InnoDB поддерживает размеры строк, превышающие 65 535 байт, но сам MySQL налагает ограничение размера строки в 65 535 для объединенного размера всех столбцов.
• Максимальный размер табличного пространства составляет четыре миллиарда страниц базы данных (64 ТБ), а минимальный размер табличного пространства немного больше 10 МБ.

MySQL: механизм хранения MyISAM

Механизм хранения MyISAM основан на более старом механизме хранения ISAM (сейчас недоступен), но имеет много полезных расширений.

Особенности механизма хранения MyISAM:

Пределы хранения	256TB	операции	нет	Блокировка детализации	Таблица
MVCC (Multiversion параллельный контроль)	нет	Поддержка типов геопространственных данных	да	Поддержка геопространственной индексации	да
B-древовидные индексы	да	T-дерево индексов	нет	Хеш-индексы	нет
Индексы полнотекстового поиска	да	Кластерные индексы	нет	Кэши данных	нет
Индексные кеши	да	Сжатые данные	да	Зашифрованные данные	да
Поддержка базы данных кластера	нет	Поддержка репликации	да	Поддержка внешнего ключа	нет
Резервное копирование / восстановление на момент времени	да	Поддержка кеша запросов	да	Обновить статистику для словаря данных	да

Каждая таблица MyISAM хранится на диске в трех файлах.

• Файл .frm хранит формат таблицы.
• Файл данных имеет расширение .MYD (MYData).
• Индексный файл имеет расширение .MYI (MYIndex).

Создание таблиц MyISAM:
Используйте оператор CREATE TABLE, чтобы создать таблицу MyISAM с предложением ENGINE. Начиная с MySQL 5.6, необходимо использовать предложение ENGINE, чтобы указать механизм хранения MyISAM, потому что InnoDB является механизмом по умолчанию. Вот пример:

Следующий оператор SHOW TABLE STATUS показывает свойства таблиц (принадлежит базе данных «tutorial»).

Основные характеристики таблиц MyISAM:

• Большие файлы длиной до 63 бит поддерживаются в файловых системах и операционных системах, которые поддерживают большие файлы.
• (2 32 ) 2 (1.844E + 19) строки разрешены в таблице MyISAM.
• Максимальное количество индексов — 64 и число столбцов — 16.
• Максимальная длина ключа составляет 1000 байтов.
• Поддерживается внутренняя обработка одного столбца AUTO_INCREMENT на таблицу.
• Вы можете поместить файл данных и индексный файл в разные каталоги на разных физических устройствах, чтобы повысить скорость с помощью параметров таблицы DATA DIRECTORY и INDEX DIRECTORY для CREATE TABLE.
• BLOB и TEXT столбцы могут быть проиндексированы.
• Значения NULL допускаются в индексированных столбцах. Это занимает от 0 до 1 байта на ключ.
• Каждый столбец символов может иметь различный набор символов.
• Поддержка истинного типа VARCHAR; столбец VARCHAR начинается с длины, хранящейся в одном или двух байтах.
• Таблицы со столбцами VARCHAR могут иметь фиксированную или динамическую длину строки.
• Сумма длин столбцов VARCHAR и CHAR в таблице может составлять до 64 КБ.
• Произвольная длина УНИКАЛЬНЫХ ограничений.

Поврежденные таблицы MyISAM:

Формат таблицы MyISAM очень надежен, но в некоторых случаях вы можете получить поврежденные таблицы, если произойдет любое из следующих событий:

• Процесс mysqld (известный как MySQL Server) завершается во время записи.
• Аппаратные сбои.
• Произошло неожиданное отключение компьютера.
• Использование внешней программы для изменения таблицы
• Программная ошибка в коде MySQL или MyISAM.

MySQL: MEMORY Storage Engine

Механизм хранения MEMORY создает таблицы, которые хранятся в памяти. Поскольку данные могут быть повреждены из-за проблем с оборудованием или электропитанием, эти таблицы можно использовать только как временные рабочие области или кэши только для чтения для данных, извлеченных из других таблиц. Когда сервер MySQL останавливается или перезапускается, данные в таблицах MEMORY теряются.

Особенности MEMORY Storage Engine:

Пределы хранения	баран	операции	нет	Блокировка детализации	Таблица
MVCC	нет	Поддержка типов геопространственных данных	нет	Поддержка геопространственной индексации	нет
B-древовидные индексы	да	T-дерево индексов	нет	Хеш-индексы	да
Индексы полнотекстового поиска	нет	Кластерные индексы	нет	Кэши данных	N / A
Индексные кеши	N / A	Сжатые данные	нет	Зашифрованные данные	да
Поддержка базы данных кластера	нет	Поддержка репликации	да	Поддержка внешнего ключа	нет
Резервное копирование / восстановление на момент времени	да	Поддержка кеша запросов	да	Обновить статистику для словаря данных	да

Создание таблиц MEMORY:
Используйте оператор CREATE TABLE для создания таблицы MEMORY с предложением ENGINE. Начиная с MySQL 5.6, необходимо использовать предложение ENGINE, чтобы указать механизм хранения MEMORY, потому что InnoDB является механизмом по умолчанию. В следующем примере показано, как создать и использовать таблицу MEMORY:

Следующий оператор SHOW TABLE STATUS показывает свойства таблиц (принадлежит базе данных «tutorial»).

Удалить таблицу MEMORY:

Индексы: Механизм хранения MEMORY поддерживает индексы HASH и BTREE. Добавляя предложение USING, вы можете указать одно или другое для данного индекса. Смотрите следующие примеры:

Когда использовать механизм хранения MEMORY:

• Операции с временными, некритическими данными, такими как управление сеансами или кэширование.
• Память в памяти для быстрого доступа и низкой задержки. Объем данных может полностью поместиться в памяти, не заставляя операционную систему выгружать страницы виртуальной памяти.
• По умолчанию ключ индекса для индекса из одного столбца может содержать до 767 байтов. То же ограничение длины применяется к любому префиксу ключа индекса.
• Внутренняя максимальная длина ключа InnoDB составляет 3500 байт, но сам MySQL ограничивает это до 3072 байт (объединенный индексный ключ в многостолбцовом индексе).
• Максимальная длина строки, за исключением столбцов переменной длины (VARBINARY, VARCHAR, BLOB и TEXT), составляет около 8000 байтов при размере страницы по умолчанию 16 КБ.
• Внутренне InnoDB поддерживает размеры строк, превышающие 65 535 байт, но сам MySQL налагает ограничение размера строки в 65 535 для объединенного размера всех столбцов.
• Максимальный размер табличного пространства составляет четыре миллиарда страниц базы данных (64 ТБ), а минимальный размер табличного пространства немного больше 10 МБ.

MySQL: MERGE Storage Engine

Механизм хранения MERGE (также известный как MRG_MyISAM) представляет собой набор идентичных таблиц MyISAM (идентичные столбцы и индексные данные в одинаковом порядке), которые можно использовать как одну таблицу. У вас должны быть привилегии SELECT, DELETE и UPDATE для таблиц MyISAM, которые вы сопоставляете с таблицей MERGE.

Создание таблиц MERGE:
Чтобы создать таблицу MERGE, необходимо указать параметр UNION = (список таблиц) (указывает, какие таблицы MyISAM использовать) в операторе CREAE TABLE. В следующем примере сначала мы создали три таблицы с двумя строками, затем объединили их в одну таблицу, используя механизм хранения MERGE:

Следующий оператор SHOW TABLE STATUS показывает свойства таблиц (принадлежит базе данных «tutorial»).

Проблема безопасности: если у пользователя есть доступ к таблице MyISAM, скажем, t1, он может создать таблицу MERGE m1, которая обращается к t1. Однако, если администратор аннулирует привилегии пользователя на t1, пользователь может продолжить доступ к данным с t1 по m1.

MySQL: CSV Storage Engine

Механизм хранения CSV хранит данные в текстовых файлах, используя формат значений, разделенных запятыми, и механизм хранения CSV всегда компилируется в сервер MySQL. Сервер создает файл формата таблицы (расширение .frm) и файл данных (расширение .csv) в каталоге базы данных при создании таблицы CSV. И имена файлов .frm и .csv начинаются с имени таблицы. Файл данных представляет собой простой текстовый файл, и механизм хранения сохраняет данные в формате значений, разделенных запятыми. В следующем примере показано, как создать и использовать таблицу CSV:

Вы можете прочитать, изменить файл 'color.CSV' с помощью приложений для работы с электронными таблицами, таких как Microsoft Excel или StarOffice Calc.

Ограничения CSV:

• Не поддерживает индексацию.
• Не поддерживает разбиение.
• Все столбцы должны иметь атрибут NOT NULL в таблице CSV.

Следующий оператор SHOW TABLE STATUS показывает свойства таблиц (принадлежит базе данных «tutorial»).

MySQL: ARCHIVE Storage Engine

Механизм хранения ARCHIVE используется для хранения большого количества неиндексированных данных в очень небольшом объеме. Механизм хранения включен в двоичные дистрибутивы MySQL. Чтобы включить этот механизм хранения (если вы собираете MySQL из исходного кода), вызовите CMake с опцией -DWITH_ARCHIVE_STORAGE_ENGINE. При создании таблицы ARCHIVE сервер создает файл формата таблицы (расширение .frm) в каталоге базы данных.

Особенности хранилища ARCHIVE:

Пределы хранения	Никто	операции	нет	Блокировка детализации	Таблица
MVCC	нет	Поддержка типов геопространственных данных	да	Поддержка геопространственной индексации	нет
B-древовидные индексы	нет	T-дерево индексов	нет	Хеш-индексы	нет
Индексы полнотекстового поиска	нет	Кластерные индексы	нет	Кэши данных	нет
Индексные кеши	нет	Сжатые данные	да	Зашифрованные данные	да
Поддержка базы данных кластера	нет	Поддержка репликации	да	Поддержка внешнего ключа	нет
Резервное копирование / восстановление на момент времени	да	Поддержка кеша запросов	да	Обновить статистику для словаря данных	да

АРХИВ поддерживает механизм хранения

• Вставить и выбрать.
• ORDER BY операции
• BLOB столбцы
• Атрибут столбца AUTO_INCREMENT. Столбец AUTO_INCREMENT может иметь уникальный или неуникальный индекс.
• Параметр таблицы AUTO_INCREMENT в операторах CREATE TABLE

ARCHIVE хранилище не поддерживает

• УДАЛИТЬ, ЗАМЕНИТЬ или ОБНОВИТЬ
• Вставка значения в столбец AUTO_INCREMENT меньше текущего максимального значения столбца.

АРХИВ хранилища: хранение и поиск

• Движок ARCHIVE использует сжатие данных без потерь zlib (см. Http://www.zlib.net/).
• Строки сжимаются при вставке.
• При извлечении строки распаковываются по требованию; нет кеша строк

MySQL: ПРИМЕР Механизма хранения

Механизм хранения EXAMPLE — это механизм-заглушка, который ничего не делает и служит примером в исходном коде MySQL, который разъясняет, как начать писать новые механизмы хранения. Чтобы проверить источник для механизма EXAMPLE, посмотрите в каталоге storage / example исходного дистрибутива MySQL. Когда вы создаете таблицу EXAMPLE:

• Сервер создает файл формата таблицы (расширение .frm) в каталоге базы данных.
• Другие файлы не создаются
• Данные не могут быть сохранены в таблице.
• Поиски возвращают пустой результат.
• Не поддерживает индексацию.

Чтобы включить механизм хранения EXAMPLE, если вы собираете MySQL из исходного кода, вызовите CMake с опцией -DWITH_EXAMPLE_STORAGE_ENGINE.

MySQL: BLACKHOLE Storage Engine

Механизм хранения BLACKHOLE действует как «черная дыра», которая принимает данные, но возвращает пустой результат. Чтобы включить механизм хранения BLACKHOLE (в случае сборки MySQL из исходного кода), вызовите CMake с параметром -DWITH_BLACKHOLE_STORAGE_ENGINE. Когда вы создаете таблицу BLACKHOLE, сервер создает файл формата таблицы (.frm) в каталоге базы данных. Механизм хранения BLACKHOLE поддерживает все виды индексов. Вот пример:

Следующий оператор SHOW TABLE STATUS показывает свойства таблиц (принадлежит базе данных «tutorial»).

MySQL: FEDERATED Storage Engine

Механизм хранения FEDERATED используется для доступа к данным из удаленной базы данных MySQL без использования технологии репликации или кластеров. Запрос локальной таблицы FEDERATED автоматически извлекает данные из удаленных (объединенных) таблиц. Данные не хранятся в локальных таблицах. Чтобы включить механизм хранения FEDERATED (в случае сборки MySQL из исходного кода), вызовите CMake с параметром -DWITH_FEDERATED_STORAGE_ ENGINE.
Чтобы включить FEDERATED (не включен по умолчанию на работающем сервере), необходимо запустить двоичный файл MySQL-сервера с помощью параметра —federated. Чтобы проверить источник для механизма FEDERATED, посмотрите каталог хранилища / объединения в исходном дистрибутиве MySQL.

Создать FEDERATED таблицу

Вы можете создать таблицу FEDERATED следующими способами:

• Использование СОЕДИНЕНИЯ
• Использование CREATE SERVER

Использование CONNECTION : Чтобы использовать этот метод, необходимо указать строку CONNECTION после типа механизма в инструкции CREATE TABLE. Смотрите следующий пример:

Формат строки подключения выглядит следующим образом:

• Схема: Распознанный протокол соединения. На данный момент в качестве значения схемы поддерживается только mysql.
• Имя пользователя для соединения должно быть создано на удаленном сервере и иметь соответствующие привилегии для выполнения необходимых действий, таких как SELECT, INSERT, UPDATE и т. Д. Над удаленной таблицей.
• Пароль для имени пользователя. (Необязательный)
• имя_хоста: имя хоста или IP-адрес удаленного сервера.
• port_num: номер порта (по умолчанию: 3306) для удаленного сервера. (Необязательный)
• db_name: имя базы данных, содержащей удаленную таблицу.
• tbl_name: имя удаленной таблицы.

Использование CREATE SERVER: чтобы использовать этот метод, необходимо указать строку CONNECTION после типа механизма в инструкции CREATE TABLE. Смотрите следующий пример:

Имя_сервера используется в строке подключения при создании новой таблицы FEDERATED.

What are MySQL database engines? [closed]

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 3 years ago .

I looked around and found some of the MySQL engines are innodb and MyISAM. Perhaps there are few more. My question is what are these database engines?

What are the differences between different MySQL engines? And more importantly, How do I decide which one to use?

4 Answers 4

I personally always use InnoDB if I have to use MySQL. It supports transaction and foreign keys while MyISAM doesn’t.

MyISAM and InnoDB are the most commonly used engines.

MyISAM is slightly faster than InnoDB, and implements the FULLTEXT index which is quite useful for integrating search capabilities. MyISAM is not transacted and doesn’t implement foreign key constraints, which is a major drawback.

But you can use the best of both and create tables with different storage engines. Some software (WordPress, I think) use Inno for most data, like relations between pages, versions etc. Records for the posts contain an ID that links to a record in a separate content table that uses MyISAM. That way, the content is stored in the table that has the best search capabilities, while most other data is stored in tables that enforce data integrity.

If I were you, I’d pick Inno, because it is the most reliable. Only use MyISAM for specific purposes if you need to.

You can configure your database to use InnoDB by default when creating new tables.

MySQL движки хранения данных

Одна из великолепных возможностей MySQL, отличная от бесплатности, широкой поддержки и быстроты, заключается в выборе различных движков хранения данных (storage engines) для различных таблиц.

MySQL предлагает 7 движков хранения данных, включая «example» — который позволяет Вам реализовать собственную библиотеку хранения.

Что-же такого великолепного в обладании всеми этими вариантами?

Каждый движок хранения данных полностью различен и спроектирован для конкретных нужд приложений.

Не зацикливаясь на одном движке (как Oracle), Вы тем самым можете оптимизировать и выбирать лучший инструмент для своей работы.

Совет: Хорошо спроектированное приложение, активно использующее MySQL, должно использовать различные движки хранения данных для различных таблиц. Если Вы все еще завязли на MyISAM таблицах, может теперь стоит, что-то пересмотреть.

Обзор движков хранения данных MySQL

MyISAM: Движок по умолчанию. Не поддерживает транзакций, средняя надежность хранения данных. Превосходная производительность чтения данных для интенсивных приложений. Большинство веб сервисов и хранилищ данных активно используют MyISAM.

HEAP: Все в памяти. Очень быстрый поиск данных, однако все они хранятся только в памяти и будут потеряны при остановке сервера. Великолепно подходит для временных таблиц.

Archive: Используется для хранения больших объемов данных без индексов, занимая меньший размер.

Merge: Коллекция MyISAM таблиц логически объединенных вместе для единого представления.

InnoDB: Транзакционный тип движка, применяемый при интенсивных операциях записи, спасибо возможности блокировки уровня строк таблицы. Великолепная восстанавливаемость и высокая надежность хранения данных. Движок InnoDB был приобретен Oracle в 2005 году.

NDB: Кластерный движок — данные автоматически разделяются и реплицируются по различным машинам, именуемым — дата узлы. Применяется для приложений, которые требуют высокой производительности с наивысшей степенью доступности. NDB хорошо работает на системах требующих высокой отдачи на операциях чтения. Для «тяжелых» приложений требующих активной записи в конкурирующей среде рассмотрите вариант с InnoDB.

Что-бы лучше понять уникальные характеристики каждого движка хранения данных, посмотрите на эту «магическую» диаграмму:

Примеры:

Ниже приведены несколько примеров использования наиболее подходящих движков хранения для различных задач:

• Поисковый движок — NDB кластер
• Логирование веб статистики — Обычные файлы для логирования с оффлайновым обработчиком и записью всей статистики в InnoDB таблицы
• Финансовые транзакции — InnoDB
• Сессионные данные — MyISAM или NDB кластер
• Локальные расчеты — HEAP
• Словари — MyISAM

Важные замечания по MyISAM таблицам:

1. Таблицы могут быть повреждены. Ежедневно архивируйте Ваши данные или установите еще один MySQL сервер для выполнения репликаций.
2. Включите авто-восстановление (auto-repair) в настройках Вашего сервера (my.cnf):
   myisam-recover=backup,force
   или рассмотрите возможность выполнения ежедневной автоматической проверки таблиц баз данных.
3. Очень быстрое чтение данных (через SELECT)
4. Конкурирующие записи полностью блокируют таблицы. Переключите все, что возможно, на оффлайн обработку записей сериями, что-бы не загружать движок сервера баз данных. (Оффлайн обработка — золотое правило, применимое для всех типов таблиц)

Важные замечания по HEAP/Memory таблицам:

Пока этот тип таблиц предлагает супер быстрый возврат данных, который работает только для небольших временных таблиц.

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

Важные замечания по InnoDB таблицам:

1. Поддержка ACID транзакций. Встроенная отказоустойчивость данных, равная надежности 99.999%. Блокировка уровня строк (сравните с полной блокировкой всей таблицы в MyISAM) означает обеспечение быстрой записи конкурирующих операций.
2. Выполнение «SELECT Count(*) FROM table» без индексов выполняется в InnoDB очень медленно и требует сканирования всей таблицы. (Для MyISAM эта операция ничего не стоит, потому что он хранит внешние записи счетчиков для каждой таблицы).
   Если Вам часто необходима операция «SELECT COUNT(*)» на таблицах InnoDB, создайте MySQL триггер на вставку/удаление, который будет увеличивать/уменьшать счетчик, когда данные добавляются или удаляются из таблицы.
3. Резервирование (бакапирование)
   Простое архивирование всех файлов таблиц для InnoDB невозможно.
   MySQLDump резервирует InnoDB очень медленно. (Если Вы настаиваете на таком резервировании, включите флаг: —opt —compress)
   Быстрое жизнеспособное резервирование, которое так-же может быть использовано как новая «ведомая» (slave) машина, это InnoDB Hot Backup.
4. Восстановление
   В InnoDB встроена поддержка восстановления, которая работает в 99% случаев автоматически. Никогда не трогайте .frm или .ibd файлы в надежде «помочь» восстановлению базы данных. Если встроенное восстановление не сработало, переключайтесь на «ведомый» сервер и восстанавливайте основной из архивов.
5. LOAD DATA INFILE в InnoDB работает очень медленно. Для операций LOAD DATA присмотритесь к использованию MyISAM таблиц.
6. InnoDB меньше, чем MyISAM, прощает выполнение запросов построенных не на индексах. InnoDB отправит Вас в «школу», что-бы быть уверенным, что каждый запрос или обновление будет запущено на индексах. Выполните непроиндексированный запрос и Вы поплатитесь за это временем исполнения.
7. Никогда не изменяйте my.cnf InnoDB лог файл, когда запущен сервер баз данных. Вы разрушите последовательный лог-номер (log sequence number) оставшись без возможность восстановления.
8. Для увеличения производительности InnoDB, присмотритесь к использованию следующих настроек (my.cnf):

Расширяемость

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

Для активно-читающей (read-heavy) среды, используйте NDB кластер или установите репликации для n MyISAM ведомых read-only машин.

Для активно-пишущей (write-heavy) среды, InnoDB с активно/пассивными репликациями будет лучшим типовым решением. Но Вы можете поэкспериментировать с NDB кластером. NDB кластер обычно медленнее чем InnoDB в операциях с активной записью, но он предлагает наивысший уровень доступности.