Глава 17. Механизмы хранения

Механизмы хранения это компоненты MySQL, которые обрабатывают операции SQL для различных табличных типов. InnoDB механизм хранения общего назначения по умолчанию, Oracle рекомендует использовать это для таблиц за исключением специализированных случаев использования. Запрос CREATE TABLE в MySQL 8.0 создает таблицы InnoDB по умолчанию.

MySQL Server использует сменную архитектуру механизма хранения, которая позволяет механизмам хранения быть загруженными, не прерывая работу.

Чтобы определить который механизмы хранения Ваш сервер поддерживает, используйте запрос SHOW ENGINES . Значение в столбце Support указывает, может ли механизм использоваться. Значения YES, NO или DEFAULT указывают, что механизм доступен, не доступен или доступен и в настоящее время установлен как механизм хранения по умолчанию.

mysql> SHOW ENGINES\G
*************************** 1. row ***************************
Engine: PERFORMANCE_SCHEMA
 Support: YES
 Comment: Performance Schema
Транзакции: NO
XA: NO
  Savepoints: NO
*************************** 2. row ***************************
Engine: InnoDB
 Support: DEFAULT
 Comment: Supports Транзакции, row-level locking, and foreign keys
Транзакции: YES
XA: YES
  Savepoints: YES
*************************** 3. row ***************************
Engine: MRG_MYISAM
 Support: YES
 Comment: Collection of identical MyISAM tables
Транзакции: NO
XA: NO
  Savepoints: NO
*************************** 4. row ***************************
Engine: BLACKHOLE
 Support: YES
 Comment: /dev/null storage engine (anything you write to it disappears)
Транзакции: NO
XA: NO
  Savepoints: NO
*************************** 5. row ***************************
Engine: MyISAM
 Support: YES
 Comment: MyISAM storage engine
Транзакции: NO
XA: NO
  Savepoints: NO
...
Эта глава касается случаев использования для механизмов хранения MySQL специального назначения. Это не покрывает InnoDB или NDB, см. главу 16 и MySQL Cluster NDB 7.5. Для продвинутых пользователей это также содержит описание архитектуры механизма хранения (см. раздел 17.11).

Для информации о поддержке механизма хранения, предлагаемых в коммерческих версиях MySQL Server, см. MySQL Enterprise Server 5.7 на Web-сайте MySQL. Доступные механизмы хранения могут зависеть от версии Enterprise Server.

Для ответов на обычно задаваемые вопросы о механизмах хранения MySQL см. раздел A.2.

Поддерживаемые механизмы хранения в MySQL 8.0

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

Выбор механизма хранения

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

Таблица 17.1. Обзор особенностей механизмов хранения

ОсобенностьMyISAM MemoryInnoDB ArchiveNDB
Пределы хранения256 TBRAM 64 TBНет384 EB
ТранзакцииНетНетДа НетДа
Степень детализации блокировкиТаблица ТаблицаСтрокаСтрокаСтрока
MVCCНетНетДаНет Нет
Картографические типы данныхДаНет ДаДаДа
Картографические индексыДаНет ДаНетНет
Индексы B-treeДаДаДа НетНет
Индексы T-treeНетНетНет НетДа
Индексы HashНетДаНет НетДа
Индексы Full-text searchДаНет ДаНетНет
Индексы ClusteredНетНетДа НетНет
Кэш данныхНетN/AДа НетДа
Кэш индексаДаN/AДа НетДа
Сжатые данныеДаНетДа ДаНет
Зашифрованные данныеДаДа ДаДаДа
Поддержка базы данных кластераНет НетНетНетДа
Поддержка репликацииДаДа ДаДаДа
Поддержка внешнего ключаНетНет ДаНетНет
Резервное копирование/восстановление момента времени ДаДаДаДаДа
Поддержка кэша запросаДаДа ДаДаДа
Статистика обновления для словаря данныхДа ДаДаДаДа

Поддержка InnoDB индексации геоданных доступна в MySQL 5.7.5 и выше.

InnoDB использует хеш-индекс внутренне для своего адаптивного хеша.

InnoDB Поддержка InnoDB FULLTEXT индексов доступна в MySQL 5.6.4 и выше.

Сжатые таблицы MyISAM поддержаны только, используя сжатый формат строки. Таблицы, используя сжатый формат строки MyISAM, доступны только для чтения.

Сжатые таблицы InnoDB требуют формата файла InnoDB Barracuda.

Шифрование табличного пространства данных доступно в MySQL 5.7 и выше.

17.1. Установка механизма хранения

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

-- ENGINE=INNODB not needed unless you have set a different
-- default storage engine.
CREATE TABLE t1 (i INT) ENGINE = INNODB;

-- Simple table definitions can be switched from one to another.
CREATE TABLE t2 (i INT) ENGINE = CSV;
CREATE TABLE t3 (i INT) ENGINE = MEMORY;
Когда Вы опускаете опцию ENGINE, механизм хранения по умолчанию используется. Это InnoDB в MySQL 8.0. Вы можете переопределить механизм по умолчанию при использовании опции --default-storage-engine при запуске сервера или задав опцию default-storage-engine в конфигурационном файле my.cnf .

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

SET default_storage_engine=NDBCLUSTER;
Механизм хранения для таблиц TEMPORARY, составленных с CREATE TEMPORARY TABLE, может быть установлен отдельно от механизма для постоянных таблиц, устанавливая переменную default_tmp_storage_engine.

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

ALTER TABLE t ENGINE = InnoDB;
См. разделы 14.1.15 и 14.1.7.

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

По умолчанию предупреждение произведено всякий раз, когда CREATE TABLE или ALTER TABLE не может использовать механизм хранения по умолчанию. Чтобы предотвратить запутывающее, непреднамеренное поведение, если желаемый механизм недоступен, включите режим SQL NO_ENGINE_SUBSTITUTION. Если желаемый механизм недоступен, эта установка производит ошибку вместо предупреждения, и таблица не будет составлена или изменена. См. раздел 6.1.8.

MySQL может сохранить таблицу, индексы и данные в одном или более файлах, в зависимости от механизма хранения. Таблица и определения столбца сохранены в словаре данных MySQL. Отдельные механизмы хранения создают любые дополнительные файлы, требуемые для таблиц, которыми они управляют. Если имя таблицы содержит специальные символы, названия табличных файлов содержат закодированные версии тех символов, как описано в разделе 10.2.3.

17.2. Механизм хранения MyISAM

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

Таблица 17.2. Особенности механизма хранения MyISAM

Пределы хранения 256 TBТранзакции НетСтепень детализации блокировки Таблица
MVCCНет Картографические типы данных Да Индексирование геоданных Да
Индексы B-tree ДаИндексы T-treeНет Индексы HashНет
Индексы Full-text search ДаКластеризуемые индексы НетКэш данныхНет
Кэш индексов ДаСжатые данныеДа Шифрование данныхДа
Поддержка базы данных кластера НетРепликация ДаПоддержка внешнего ключа Нет
Резервное копирование/восстановление момента времениДаКэш запросов ДаСтатистика обновления для словаря данныхДа

Каждая таблица MyISAM сохранена на диске в двух файлах. У файлов есть имена, которые начинаются с имени таблицы и имеют расширение, чтобы указать на тип файла. Файл с данными имеет расширение .MYD (MYData). Индексный файл имеет расширение .MYI (MYIndex). Табличное определение сохранено в словаре данных MySQL.

Чтобы определить явно, что Вы хотите получить таблицу MyISAM, укажите на это табличной опцией ENGINE:

CREATE TABLE t (i INT) ENGINE = MYISAM;
В MySQL 8.0 обычно необходимо использовать ENGINE, чтобы определить механизм хранения MyISAM, потому что InnoDB механизм по умолчанию.

Вы можете проверить или восстановить таблицы MyISAM с помощью mysqlcheck или myisamchk . Вы можете также сжать таблицы MyISAM с myisampack , чтобы они занимали намного меньше пространства. См. разделы 5.5.3, 5.6.4 и 5.6.6.

В MySQL 8.0 механизм хранения MyISAM не оказывает поддержки разделения. Разделенные таблицы MyISAM, составленные в предыдущих версиях MySQL, не могут использоваться в MySQL 8.0. Для получения дополнительной информации см. раздел 20.6.2. Для справки по обновлению таких таблиц так, чтобы они могли использоваться в MySQL 8.0, см. раздел 2.10.1.1.

У таблиц MyISAM есть следующие характеристики:

MyISAM также поддерживает следующие функции:

Дополнительные ресурсы

17.2.1. Опции запуска MyISAM

Следующие опции mysqld могут использоваться, чтобы изменить поведение таблиц MyISAM. Для дополнительной информации см. раздел 6.1.4.

Таблица 17.3. Обзор опций и переменных MyISAM

ИмяCmd-Line Файл опцииСистемная переменная Статусная переменнаяКонтекст переменной Динамическая
bulk_insert_buffer_size ДаДаДа ОбаДа
concurrent_insertДаДаДа ГлобальныйДа
delay-key-writeДаДа ГлобальныйДа
- Переменная: delay_key_write Да ГлобальныйДа
have_rtree_keys Да ГлобальныйНет
key_buffer_sizeДаДаДа ГлобальныйДа
log-isam ДаДа
myisam-block-sizeДаДа
myisam_data_pointer_sizeДаДаДа ГлобальныйДа
myisam_max_sort_file_sizeДаДаДа ГлобальныйДа
myisam_mmap_sizeДаДаДа ГлобальныйНет
myisam-recover-optionsДаДа
- Переменная: myisam_recover_options
myisam_recover_options Да ГлобальныйНет
myisam_repair_threadsДаДаДа ОбаДа
myisam_sort_buffer_sizeДаДаДа ОбаДа
myisam_stats_methodДаДаДа ОбаДа
myisam_use_mmapДаДаДа ГлобальныйДа
skip-concurrent-insertДаДа
- Переменная: concurrent_insert
tmp_table_size ДаДаДа ОбаДа

Следующие системные переменные затрагивают поведение таблиц MyISAM. Для дополнительной информации см. раздел 6.1.5.

Автоматическое восстановление активировано, если Вы запускаете mysqld с опцией --myisam-recover-options. В этом случае когда сервер открывает таблицу MyISAM, он проверяет, отмечена ли таблица как "разрушено" или не является ли переменная количества открытий для таблицы 0, и Вы выполняете сервер с внешней отключенной блокировкой. Если любое из этих условий истина, происходит следующее:

Если восстановление не в состоянии возвратить все строки ранее завершенных запросов, и Вы не определяли FORCE в значении опции --myisam-recover-options, автоматический ремонт прерывается с сообщением об ошибке в журнале ошибок:

Error: Couldn't repair table: test.g00pages
Если Вы определяете FORCE, вместо этого будет предупреждение:
Warning: Found 344 of 354 rows when repairing ./test/g00pages
Если автоматическое значение восстановления включает BACKUP, процесс восстановления создает файлы с названиями вида tbl_name-datetime.BAK. У Вас должен быть скрипт cron, который автоматически перемещает эти файлы из каталогов базы данных, чтобы сделать копию.

17.2.2. Необходимое пространство для ключей

Таблицы MyISAM используют индексы B-tree. Вы можете примерно вычислить размер для индексного файла как (key_length+4)/0.67, суммированный по всем ключам. Это для худшего случая, когда все ключи вставлены в сортированном порядке, и у таблицы нет никаких сжатых ключей.

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

В таблицах MyISAM Вы можете также сжать числовые префиксы, определяя опцию PACK_KEYS=1, когда Вы составляете таблицу. Числа сохранены со старшим байтом сначала, таким образом, это помогает, когда у Вас есть много ключей целого числа, у которых есть идентичный префикс.

17.2.3. Табличные форматы хранения MyISAM

MyISAM поддерживает три различных формата хранения. Два из них, фиксрованный и динамический, выбраны автоматически в зависимости от типа столбцов, которые Вы используете. Третий, сжатый, формат может быть создан только с помощью myisampack (см. раздел 5.6.6 ).

Когда Вы используете CREATE TABLE или ALTER TABLE для таблицы, которая не имеет столбцов BLOB или TEXT, Вы можете привести формат таблицы к FIXED или DYNAMIC с опцией ROW_FORMAT.

См. раздел 14.1.15 для информации о ROW_FORMAT.

Вы можете распаковать сжатые таблицы MyISAM, используя myisamchk--unpack, см. раздел 5.6.4.

17.2.3.1. Табличные характеристики (фиксированная длина)

Статический формат значение по умолчанию для таблицы MyISAM. Это используется, когда таблица не содержит столбцов переменной длины (VARCHAR, VARBINARY, BLOB или TEXT). Каждая строка сохранена, используя постоянное число байтов.

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

Формат строки фиксированной длины доступен только для таблиц без столбцов BLOB или TEXT. Составление таблицы с этими столбцами с явным указанием ROW_FORMAT не будет создавать ошибку или предупреждение, спецификация формата будет проигнорирована.

У таблиц статического формата есть эти характеристики:

17.2.3.2. Динамические табличные характеристики

Динамический формат хранения используется, если таблица MyISAM содержит любые столбцы переменной длины (VARCHAR, VARBINARY, BLOB или TEXT) или если таблица была составлена с опцией ROW_FORMAT=DYNAMIC.

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

Вы можете использовать OPTIMIZE TABLE или myisamchk -r для дефрагментации таблицы. Если у Вас есть столбцы фиксированной длины, к которым Вы получаете доступ или часто изменяете в таблице, которая также содержит некоторые столбцы переменной длины, может быть хорошей идеей переместить столбцы переменной длины в другие таблицы, чтобы избежать фрагментации.

У таблиц динамического формата есть эти характеристики:

17.2.3.3. Сжатые табличные характеристики

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

У сжатых таблиц есть следующие характеристики:

В то время как сжатая таблица только для чтения, и Вы не можете поэтому обновить или добавить строки в таблице, операции DDL (язык определения данных) все еще допустимы. Например, Вы все еще можете использовать DROP для удаления и TRUNCATE TABLE, чтобы освободить таблицу.

17.2.4. Проблемы таблиц MyISAM

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

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

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

Типичные признаки поврежденной таблицы:

Вы можете проверить здоровье таблицы MyISAM, используя запрос CHECK TABLE и провести ремонт поврежденной таблицы MyISAM с REPAIR TABLE. Когда mysqld не работает, Вы можете также проверить или восстановить таблицу с помощью myisamchk. См. разделы 14.7.2.2, 14.7.2.5 и 5.6.4.

Если Ваши таблицы становятся поврежденными часто, Вы должны попытаться определить, почему это происходит. Самая важная вещь состоит в том, стала ли таблица поврежденной в результате катастрофического отказа сервера. Вы можете проверить это легко, ища недавнее сообщение restarted mysqld в журнале ошибок. Если есть такое сообщение, вероятно, что табличное повреждение результат сбоя сервера. Иначе повреждение, возможно, произошло во время нормального функционирования. Это ошибка. Вы должны попытаться создать восстанавливаемый прецедент, который демонстрирует проблему. См. разделы B.5.3.3 и 26.5.

17.2.4.2. Проблемы от таблиц, не закрываемых должным образом

Каждый индексный файл MyISAM (.MYI) имеет счетчик в заголовке, который может использоваться, чтобы проверить, была ли таблица закрыта должным образом. Если Вы получаете следующее предупреждение от CHECK TABLE или myisamchk , это означает, что этот счетчик вышел из синхронизации:

clients are using or haven't closed the table properly
Это предупреждение не обязательно означает, что таблица повреждена, но Вы должны, по крайней мере, проверить таблицу.

Счетчик работает следующим образом:

Другими словами, счетчик может стать неправильным только при этих условиях:

17.3. Механизм хранения MEMORY

Механизм хранения MEMORY (прежде известный как HEAP) составляет таблицы специального назначения с содержанием, которое сохранено в памяти. Поскольку данные уязвимы для катастрофических отказов, проблемы аппаратных средств или отключения электричества, эти таблицы используют в качестве временных рабочих областей или кэшей только для чтения для данных, которые вытягивают из других таблиц.other tables.

Таблица 17.4. Особенности механизма хранения MEMORY

Пределы хранения RAMТранзакции НетСтепень детализации блокировки Таблица
MVCCНет Картографические типы данныхНет Индексирование геоданных Нет
Индексы B-tree ДаИндексы T-treeНет Индексы HashДа
Индексы Full-text search НетКластеризуемые индексы НетКэш данныхN/A
Кэш индексовN/A Сжатые данныеНет Шифрование данныхДа
Поддержка базы данных кластера НетРепликация ДаПоддержка внешнего ключа Нет
Резервное копирование/восстановление момента времениДаКэш запросов ДаСтатистика обновления для словаря данныхДа

Когда использовать MEMORY или MySQL Cluster. Разработчики приложений, которые используют механизм хранения MEMORY для важных, высоконадежных или часто обновляемых данных должны рассмотреть, является ли MySQL Cluster лучшим выбором. Типичный случай использования для механизма MEMORY имеет эти характеристики:

MySQL Cluster предлагает те же самые особенности как механизм MEMORY с более высокими исполнительными уровнями и обеспечивает дополнительные функции, недоступные с MEMORY:

Для отчета с более подробным сравнением механизмов хранения MEMORY и MySQL Cluster см. Scaling Web Services with MySQL Cluster: An Alternative to the MySQL Memory Storage Engine. Этот отчет включает исследование качества работы этих двух технологий и руководство, описывающее, как существующие пользователи MEMORY могут мигрировать на MySQL Cluster.

Таблицы MEMORY не могут быть разделены.

Технические характеристики

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

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

В зависимости от видов запросов, выполненных на таблицах MEMORY, Вы могли бы создать индексы как структуру данных хеша по умолчанию (для того, чтобы искать единственные значения, основанные на уникальном ключе) или структуру данных B-tree общего назначения (для всех видов запросов, вовлекающих равенство, неравенство или операторы диапазона, такие как "меньше чем" или "больше чем"). Следующие разделы иллюстрируют синтаксис для того, чтобы создать оба вида индексов.

Характеристики таблиц MEMORY

Механизм хранения MEMORY не создает файлов на диске. Табличное определение сохранено в словаре данных MySQL.

У MEMORY таблиц есть следующие характеристики:

DDL-операции для таблиц MEMORY

Чтобы создать таблицу MEMORY, определите пункт ENGINE=MEMORY в CREATE TABLE.

CREATE TABLE t (i INT) ENGINE = MEMORY;
Как обозначено именем механизма, таблицы MEMORY сохранены в памяти. Они используют хеш-индексы по умолчанию, которые делают их очень быстрыми для поисков единственного значения и очень полезными для того, чтобы составить временные таблицы. Однако, когда сервер закрывается, все строки, сохраненные в таблицах MEMORY, потеряны. Сами таблицы продолжают существовать, потому что их определения сохранены в словаре данных MySQL, но они пусты, когда сервер перезапускается.

Этот пример показывает, как Вы могли бы создать, использовать и удалить таблицу MEMORY:

mysql> CREATE TABLE test ENGINE=MEMORY
    -> SELECT ip, SUM(downloads) AS down
    ->        FROM log_table GROUP BY ip;
mysql> SELECT COUNT(ip),AVG(down) FROM test;
mysql> DROP TABLE test;
Максимальный размер таблиц MEMORY ограничен системной переменной max_heap_table_size , у которой есть значение по умолчанию 16 МБ. Провести в жизнь различные пределы размера для таблиц MEMORY можно, изменив значение этой переменной. Значение в действительности для CREATE TABLE, последующего ALTER TABLE или TRUNCATE TABLE, это значение, используемое для жизни таблицы. Перезапуск сервера также устанавливает максимальный размер существующих таблиц MEMORY к глобальной max_heap_table_size. Вы можете установить размер для отдельных таблиц как описано позже в этом разделе.

Индексы

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

CREATE TABLE lookup (id INT, INDEX USING HASH (id)) ENGINE = MEMORY;
CREATE TABLE lookup (id INT, INDEX USING BTREE (id)) ENGINE = MEMORY;

Таблицы MEMORY могут иметь до 64 индексов на таблицу, 16 столбцов на индексов и максимальную длину ключа 3072 байтов.

Если табличный хеш индекс имеет высокую степень ключевого дублирования (многие индексные записи содержат то же самое значение), обновления таблицы, которые затрагивают значения ключа и все удаления значительно медленнее. Степень этого замедления пропорциональна степени дублирования (или обратно пропорциональна количеству элементов). Вы можете использовать индекс BTREE, чтобы избежать этой проблемы.

У таблиц MEMORY могут быть групповые ключи. Это необычная особенность выполнения хеш-индекса.

Столбцы, которые индексированы, могут содержать значения NULL .

Создаваемые пользователем и временные таблицы

Табличное содержание MEMORY сохранено в памяти, которую совместно используют с внутренними временными таблицами, которые сервер составляет на лету, обрабатывая запросы. Однако, два типа таблиц отличаются: таблицы MEMORY не подвергаются преобразованию хранения, тогда как внутренние временные таблицы:

Загрузка данных

Чтобы заполнить таблицу MEMORY, когда сервер MySQL запускается, Вы можете использовать опцию --init-file. Например, Вы можете поместить запросы INSERT INTO ... SELECT или LOAD DATA INFILE в этот файл, чтобы загрузить таблицу из постоянного хранилища данных. См. разделы 6.1.4 и 14.2.6.

Таблицы MEMORY и репликация

Таблицы MEMORY становятся пустыми, когда сервер закрыт и перезапущен. Если сервер ведущее устройство, его ведомые устройства не знают, что эти таблицы стали пустыми, таким образом, Вы видите устаревший контент, если Вы выбираете данные из таблиц на ведомых устройствах. Синхронизировать таблицы MEMORY ведущего и ведомого устройств, когда таблица MEMORY используется на ведущем устройстве, можно, добавив в двоичный журнал ведущего устройства запрос DELETE, чтобы освободить таблицу на ведомых устройствах также. У ведомого устройства все еще есть устаревшие данные в таблице во время интервала между перезапуском ведущего устройства и его первым использованием таблицы. Чтобы избежать этого интервала, когда прямой запрос к ведомому устройству мог возвратить устаревшие данные, используйте опцию --init-file, чтобы заполнить таблицу MEMORY на ведущем устройстве при запуске.

Управление использованием памяти

Сервер нуждается в достаточной памяти, чтобы поддержать все таблицы MEMORY, которые используются в то же самое время.

Память не восстановлена, если Вы удаляете отдельные строки из таблицы. Память восстановлена только, когда вся таблица удалена. Память, которая ранее использовалась для удаленных строк, снова будет использована для новых строк в пределах той же самой таблицы. Чтобы освободить всю память, используемую таблицей, когда Вы больше не требуете ее содержания, выполните DELETE или TRUNCATE TABLE, чтобы удалить все строки или удалить таблицу в целом, используя DROP TABLE. Чтобы освободить память, используемую удаленными строками, надо использовать ALTER TABLE ENGINE=MEMORY.

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

SUM_OVER_ALL_BTREE_KEYS(max_length_of_key +
                        sizeof(char*) * 4) +
SUM_OVER_ALL_HASH_KEYS(sizeof(char*) * 2) +
ALIGN(length_of_row + 1, sizeof(char*))
ALIGN() представляет фактор округления, чтобы заставить длину строки быть точно кратной размеру указателя char sizeof(char*) = 4 на 32-bit системах и 8 на 64-bit машинах.

Как упомянуто ранее, переменная max_heap_table_size устанавливает предел для максимального размера таблиц MEMORY. Чтобы управлять максимальным размером для отдельных таблиц, установите сеансовое значение этой переменной прежде, чем составить каждую таблицу. Не изменяйте глобальное значение max_heap_table_size , если Вы не предназначаете значение, которое будет использоваться для таблиц MEMORY, составленных всеми клиентами. Следующий пример создает две таблицы MEMORY с максимальным размером 1 МБ и 2 МБ, соответственно:

mysql> SET max_heap_table_size = 1024*1024;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE t1 (id INT, UNIQUE(id)) ENGINE = MEMORY;
Query OK, 0 rows affected (0.01 sec)

mysql> SET max_heap_table_size = 1024*1024*2;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE TABLE t2 (id INT, UNIQUE(id)) ENGINE = MEMORY;
Query OK, 0 rows affected (0.00 sec)
Обе таблицы возвращаются к глобальному значению max_heap_table_size , если сервер перезапускается.

Вы можете также определить табличную опцию MAX_ROWS в CREATE TABLE для таблиц MEMORY, чтобы обеспечить подсказку о числе строк, которое Вы планируете сохранить в них. Это не позволяет таблице вырасти вне max_heap_table_size , которое все еще действует как ограничение на максимальный табличный размер. Для максимальной гибкости в возможности использования MAX_ROWS, установите max_heap_table_size по крайней мере, столь же высоко как значение, к которому Вы хотите вырастить каждую таблицу MEMORY.

Дополнительные ресурсы

Форум, посвященный механизму хранения MEMORY, доступен на http://forums.mysql.com/list.php?92.

17.4. Механизм хранения CSV

Механизм хранения CSV хранит данные в текстовых файлах, используя отделенный запятыми формат значений.

Механизм хранения CSV всегда собирается в сервер MySQL.

Чтобы исследовать механизм CSV, см. каталог storage/csv дистрибутива исходных текстов MySQL.

Когда Вы создаете таблицу CSV, сервер создает файл с данными. Имя файла с данными начинается с имени таблицы и имеет расширение .CSV. Файл с данными это файл простого текста. Когда Вы сохраняете данные в таблицу, механизм хранения сохраняет это в файл с данными в отделенном запятыми формате значений.

mysql> CREATE TABLE test (i INT NOT NULL, c CHAR(10) NOT NULL)
    ->        ENGINE = CSV;
Query OK, 0 rows affected (0.12 sec)

mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM test;
+---+------------+
| i | c          |
+---+------------+
| 1 | record one |
| 2 | record two |
+---+------------+
2 rows in set (0.00 sec)
Составление таблицы CSV также создает соответствующий метафайл, который хранит статус таблицы и число строк, которые существуют в таблице. Название этого файла то же самое, как название таблицы с расширением CSM.

Если Вы исследуете файл test.CSV в каталоге базы данных, создаваемый, выполняя предыдущие запросы, его содержание должно быть похожим на это:

"1","record one"
"2","record two"
Этот формат может быть считан и даже записан приложениями для обработки электронных таблиц, такими как Microsoft Excel или StarOffice Calc.

17.4.1. Восстановление и проверка таблиц CSV

Механизм хранения CSV поддерживает CHECK и REPAIR, чтобы проверить и если возможно отремонтировать поврежденную таблицу CSV.

Запрос CHECK проверяет файл CSV на законность, ища правильные полевые разделители, экранированные области, правильное число областей по сравнению с табличным определением и существование соответствующего метафайла. Первая недопустимая обнаруженная строка сообщит об ошибке. Проверка допустимой таблицы производит вывод как показано ниже:

mysql> check table csvtest;
+--------------+-------+----------+----------+
| Table        | Op    | Msg_type | Msg_text |
+--------------+-------+----------+----------+
| test.csvtest | check | status   | OK       |
+--------------+-------+----------+----------+
1 row in set (0.00 sec)
Проверка на поврежденной таблице возвращает ошибку:
mysql> check table csvtest;
+--------------+-------+----------+----------+
| Table        | Op    | Msg_type | Msg_text |
+--------------+-------+----------+----------+
| test.csvtest | check | error    | Corrupt  |
+--------------+-------+----------+----------+
1 row in set (0.01 sec)
Если проверка терпит неудачу, таблица отмечена как разрушенная. Как только таблица была отмечена как поврежденная, она автоматически восстановлена, когда Вы в следующий раз запустите CHECK или выполните SELECT. Соответствующее поврежденное состояние и новое состояние будут выведены на экран из CHECK:
mysql> check table csvtest;
+--------------+-------+----------+----------------------------+
| Table        | Op    | Msg_type | Msg_text                   |
+--------------+-------+----------+----------------------------+
| test.csvtest | check | warning  | Table is marked as crashed |
| test.csvtest | check | status   | OK                         |
+--------------+-------+----------+----------------------------+
2 rows in set (0.08 sec)
Чтобы восстановить таблицу, Вы можете использовать REPAIR, это копирует так много допустимых строк существующих данных CSV, насколько возможно, а затем заменяет существующий файл CSV восстановленными строками. Любые строки вне поврежденных данных потеряны.
mysql> repair table csvtest;
+--------------+--------+----------+----------+
| Table        | Op     | Msg_type | Msg_text |
+--------------+--------+----------+----------+
| test.csvtest | repair | status   | OK       |
+--------------+--------+----------+----------+
1 row in set (0.02 sec)

Во время ремонта только строки из файла CSV до первой поврежденной строки скопированы к новой таблице. Все другие строки от первой поврежденной строки до конца таблицы удалены, даже допустимые строки.

17.4.2. Ограничения CSV

Механизм хранения CSV не поддерживает индексацию.

Механизм хранения CSV не поддерживает разделение.

890

Все таблицы, которые Вы создаете с использованием механизма хранения CSV должны иметь признак NOT NULL на всех столбцах. Однако, для обратной совместимости, Вы можете продолжить использовать таблицы со столбцами, допускающими null, которые создавались в предыдущих выпусках MySQL (Bug #32050).

17.5. Механизм хранения ARCHIVE

Механизм хранения ARCHIVE производит таблицы специального назначения, которые хранят большое количество неиндексированных данных в очень маленьком виде.

Таблица 17.5. Особенности механизма хранения ARCHIVE

Пределы хранения НетТранзакцииНет Степень детализации блокировки Строка
MVCCНет Картографические типы данныхДа Индексирование геоданных Нет
Индексы B-tree НетИндексы T-treeНет Индексы HashНет
Индексы Full-text search НетКластеризуемые индексы НетКэш данных Нет
Кэш индексов НетСжатые данныеДа Шифрование данныхДа
Поддержка базы данных кластера НетРепликация ДаПоддержка внешнего ключа Нет
Резервное копирование/восстановление момента времениДаКэш запросов ДаСтатистика обновления для словаря данныхДа

Механизм хранения ARCHIVE включен в двоичные дистрибутивы MySQL. Чтобы включить этот механизму хранения, если Вы создаете MySQL из исходных текстов, вызовите CMake с опцией -DWITH_ARCHIVE_STORAGE_ENGINE.

Исходные тексты механизма ARCHIVE находятся в каталоге storage/archive исходных текстов MySQL.

Когда Вы создаете таблицу ARCHIVE, механизм хранения создает файлы с именами, которые начинаются с имени таблицы. У файла с данными есть расширение .ARZ. Файл .ARN может появиться во время операций оптимизации. Вы можете проверить, доступен ли механизм хранения ARCHIVE с помощью запроса SHOW ENGINES.

Механизм ARCHIVE поддерживает INSERT, REPLACE и SELECT, но не DELETE или UPDATE. Это действительно поддерживает ORDER BY, столбцы BLOB. Механизм ARCHIVE использует блокировку на уровне строки.

Механизм ARCHIVE поддерживает признак столбца AUTO_INCREMENT. У столбца AUTO_INCREMENT может быть уникальный или групповой индекс. Попытка создать индексирование на любом другом столбце приводит к ошибке. Механизм ARCHIVE также поддерживает табличную опцию AUTO_INCREMENT в CREATE TABLE, чтобы определить начальное значение последовательности для новой таблицы.

ARCHIVE не поддерживает вставку значения в столбец AUTO_INCREMENT меньше, чем текущее максимальное значение столбца. Попытки сделать так приводят к ошибке ER_DUP_KEY.

Механизм ARCHIVE игнорирует столбцы BLOB, если их не требуют.

Механизм ARCHIVE не поддерживает разделение.

Хранение: Строки сжаты, когда они вставлены. ARCHIVE использует zlib сжатие данных без потерь (см. http://www.zlib.net/). Вы можете использовать OPTIMIZE TABLE , чтобы проанализировать таблицу и упаковать ее в меньший формат (о причинах использования OPTIMIZE TABLE см. позже в этом разделе). Механизм также поддерживает CHECK TABLE. Есть несколько типов вставок, которые используются:

Извлечение: при извлечении строки рассжаты по требованию, нет никакого кэша строки. SELECT выполняет полное сканирование таблицы: когда SELECT происходит, это узнает, сколько строк в настоящее время доступно и читает это число строк. SELECT выполнен как последовательное чтение. Отметьте, что многие запросы SELECT во время вставки могут ухудшить сжатие, если только не используются оптовые вставки. Чтобы достигнуть лучшего сжатия, Вы можете использовать OPTIMIZE TABLE или REPAIR TABLE. Число строк в таблицах ARCHIVE, о которых сообщает SHOW TABLE STATUS, всегда точно. См. разделы 14.7.2.4, 14.7.2.5 и 14.7.5.36.

Дополнительные ресурсы

17.6. Механизм хранения BLACKHOLE

Механизм хранения BLACKHOLE действует как дыра памяти, который принимает данные, но не хранит их. Извлечения всегда возвращают пустой результат:

mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM test;
Empty set (0.00 sec)
Чтобы включить механизм хранения BLACKHOLE, если Вы создаете MySQL из исходных текстов, вызовите CMake с опцией -DWITH_BLACKHOLE_STORAGE_ENGINE.

Механизм BLACKHOLE находится в каталоге sql исходных текстов MySQL.

Когда Вы создаете таблицу BLACKHOLE, сервер создает табличное определение в глобальном словаре данных. Нет никаких файлов, связанных с таблицей.

Механизм хранения BLACKHOLE поддерживает все виды индексов. Таким образом, Вы можете включать индексные декларации в табличном определении.

Механизм хранения BLACKHOLE не поддерживает разделение.

Вы можете проверить доступен ли механизм хранения BLACKHOLE с помощью SHOW ENGINES.

Вставки в таблицу BLACKHOLE не хранят данных, но если двоичное журналирование, основанное на запросе, включено, запросы SQL зарегистрированы и копируются к ведомым серверам. Это может быть полезно как повторитель или фильтр.

Используя основанное на строке двоичное журналирование, обновления и удаления пропущены, но не зарегистрированы и не применены. Поэтому Вы должны использовать STATEMENT для формата двоичного журналирования, а не ROW или MIXED.

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

Ведущее устройство пишет двоичный журнал. Пустой процесс mysqld обрабатывает действия как ведомое устройство, применяя желаемую комбинацию правил replicate-do-* и replicate-ignore-*, и пишет отфильтрованный результат в собственный двоичный журнал. См. раздел 19.1.6. Этот фильтруемый журнал обеспечен ведомому устройству.

Фиктивный процесс фактически не хранит данных, таким образом есть небольшая обработка, выполняя дополнительный процесс mysqld на ведущем узле. Этот тип установки может быть повторен с дополнительными ведомыми устройствами репликации.

Триггеры INSERT для таблиц BLACKHOLE работают как ожидалось. Однако, потому что BLACKHOLE фактически не хранит данных, триггеры UPDATE и DELETE не активированы: предложение FOR EACH ROW в определении не применяется, потому что нет никаких строк.

Другие возможные применения для механизма хранения BLACKHOLE включают:

Механизм BLACKHOLE осведомлен о транзакции, в том смысле, что переданные транзакции записаны в двоичный журнал, а отмененные нет.

Механизм Blackhole и столбцы Auto Increment:

Механизм Blackhole пустой. Любые операции, выполненные на табличном использовании Blackhole не будут иметь никакого эффекта. Это должно быть в памяти, рассматривая поведение столбцов первичного ключа, имеющих auto increment. Механизм не будет автоматически постепенно увеличивать значения полей и не сохраняет статус полей auto increment. У этого есть важные значения в репликации.

Рассмотрите следующий сценарий, где все три из следующих условий применяются:

  1. На главном сервере есть blackhole таблица с полем auto increment, которое является первичным ключом.

  2. На ведомом устройстве та же самая таблица существует, но с использованием механизма MyISAM.
  3. Вставки выполнены в таблицу ведущего устройства, явно не устанавливая значение auto increment в запросе INSERT непосредственно или посредством использования SET INSERT_ID.

В этом сценарии репликация потерпит неудачу с ошибкой дублирования записи на столбце первичного ключа.

При репликации на основе запроса значение INSERT_ID в контексте всегда будет то же самое. Репликация поэтому потерпит неудачу из-за попытки вставки строки с двойным значением столбца первичного ключа.

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

Фильтрация столбца

При репликации на основе строки (binlog_format=ROW ), ведомое устройство, где последние столбцы отсутствуют в таблице, поддержано, как описано в разделе 19.4.1.10 .

Эта фильтрация работает на ведомой стороне, то есть, столбцы скопированы ведомому устройству прежде, чем они будут отфильтрованы. Есть по крайней мере два случая, где нежелательно скопировать столбцы к ведомому устройству:

  1. Если данные являются конфиденциальными, таким образом, у ведомого сервера не должно быть доступа к ним.

  2. Если у ведущего устройства есть много ведомых устройств, фильтрование прежде, чем послать в ведомые устройства, может уменьшить сетевой трафик.

Основная фильтрация столбца может быть достигнута, используя BLACKHOLE. Это выполнено подобном тому, как основная табличная фильтрация достигнута: при использовании BLACKHOLE и опций --replicate-do-table или --replicate-ignore-table.

Установка для ведущего устройства:

CREATE TABLE t1 (public_col_1, ..., public_col_N,
                 secret_col_1, ..., secret_col_M) ENGINE=MyISAM;
Установка для ведомого устройства, которому доверяют:
CREATE TABLE t1 (public_col_1, ..., public_col_N) ENGINE=BLACKHOLE;
Установка для ведомого устройства, которому не доверяют:
CREATE TABLE t1 (public_col_1, ..., public_col_N) ENGINE=MyISAM;

17.7. Механизм хранения MERGE

Механизм хранения MERGE, также известный как MRG_MyISAM, это набор идентичных таблиц MyISAM, которые могут использоваться в качестве одной. "Идентичные" означает, что все таблицы имеют идентичные столбцы и индексную информацию. Вы не можете слить таблицы MyISAM, в которых столбцы перечислены в различном порядке, не имеют точно тех же самых столбцов или имеют индексы в различном порядке. Однако, любая из таблиц MyISAM может быть сжата с myisampack. См. раздел 5.6.6. Различия в таких табличных опциях, как AVG_ROW_LENGTH , MAX_ROWS или PACK_KEYS не имеют значения.

Альтернатива таблице MERGE это разделенная таблица, которая хранит разделение единственной таблицы в отдельных файлах и позволяет некоторым операциям быть выполненными более эффективно. Для получения дополнительной информации см. главу 20.

Когда Вы создаете таблицу MERGE, MySQL создает файл .MRG на диске, который содержит названия основных таблиц MyISAM, которые должны использоваться в качестве одной. Формат таблицы MERGE сохранен в словаре данных MySQL. Основные таблицы не должны быть в той же самой базе данных, что и MERGE.

Вы можете использовать SELECT, DELETE, UPDATE и INSERT на таблицах MERGE. Вы должны иметь привилегии SELECT, DELETE и UPDATE на таблицах MyISAM, которые Вы отображаете на таблицу MERGE.

Использование таблицы MERGE влечет за собой следующий вопрос безопасности: если у пользователя есть доступ к MyISAM-таблице t, этот пользователь может создать MERGE-таблицу m, которая получает доступ к t. Однако, если привилегии пользователя на t впоследствии отменяются, пользователь может продолжить получать доступ к t через m.

Использование DROP TABLE с таблицей MERGE удалит только спецификацию MERGE. Основные таблицы не затронуты.

Чтобы создать таблицу MERGE, Вы должны определить опцию UNION=(list-of-tables), которая указывает, которые таблицы MyISAM использовать. Вы можете произвольно определить опцию INSERT_METHOD, чтобы управлять, как вставлять в таблицу MERGE. Используйте значение FIRST или LAST, чтобы вставки юыли сделаны в первой или последней основной таблице, соответственно. Если Вы не определяете INSERT_METHOD или если Вы определяете это со значением NO, вставка в таблицу MERGE не разрешена, и попытка ее сделать вернет ошибку.

Следующий пример показывает, как создать таблицу MERGE:

mysql> CREATE TABLE t1 (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    ->                  message CHAR(20)) ENGINE=MyISAM;
mysql> CREATE TABLE t2 (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    ->                  message CHAR(20)) ENGINE=MyISAM;
mysql> INSERT INTO t1 (message) VALUES ('Testing'),('table'),('t1');
mysql> INSERT INTO t2 (message) VALUES ('Testing'),('table'),('t2');
mysql> CREATE TABLE total (a INT NOT NULL AUTO_INCREMENT,
    ->        message CHAR(20), INDEX(a))
    ->        ENGINE=MERGE UNION=(t1,t2) INSERT_METHOD=LAST;
Столбец a индексирован как PRIMARY KEY в основной таблице MyISAM, но не в таблице MERGE. Там это индексировано, но не как PRIMARY KEY, так как таблица MERGE не может провести в жизнь уникальность по набору основных таблиц. Точно так же столбец с индексом UNIQUE в основных таблицах, должен быть индексирован в MERGE, но не как UNIQUE.

После создания таблицы MERGE Вы можете использовать ее, чтобы создать запросы, которые воздействуют на группу таблиц в целом:

mysql> SELECT * FROM total;
+---+---------+
| a | message |
+---+---------+
| 1 | Testing |
| 2 | table   |
| 3 | t1      |
| 1 | Testing |
| 2 | table   |
| 3 | t2      |
+---+---------+
Чтобы переопределить таблицу MERGE к иному набору таблиц MyISAM, Вы можете использовать один из следующих методов:

Основные табличные определения и индексы должны соответствовать близко определению MERGE. Соответствие проверено, когда таблица, которая является частью MERGE, открыта, а не когда MERGE-таблица составлена. Если какая-либо таблица не проходит проверку соответствия, работа, которая вызвала открытие таблицы, терпит неудачу. Это означает, что изменения определений таблиц в пределах MERGE может вызвать отказ при доступе к MERGE. Проверка соответствия относится к каждой таблице:

Если таблица MERGE не может быть открыта или использоваться из-за проблемы с основной таблицей, CHECK TABLE покажет информацию о том, которая таблица вызвала проблему.

Дополнительные ресурсы

17.7.1. Табличные преимущества и недостатки MERGE

Таблицы MERGE могут помочь Вам решить следующие проблемы:

Недостатки MERGE-таблицы:

17.7.2. Табличные проблемы MERGE

Следующее известные проблемы с таблицами MERGE:

17.8. Механизм хранения FEDERATED

Механизм хранения FEDERATED позволяет Вам доступ к данным от удаленной базы данных MySQL, не используя технологию кластера или репликации. Запросы к локальной таблице FEDERATED автоматически вытягивают данные из удаленных (объединенных) таблиц. Никакие данные не хранятся в местных таблицах.

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

Механизм хранения FEDERATED не включен по умолчанию в рабочем сервере, чтобы его включить, Вы должны запустить сервер MySQL с опцией --federated.

Исходный текст механизма FEDERATED находится в каталоге storage/federated исходных текстов MySQL.

17.8.1. Краткий обзор механизма хранения FEDERATED

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

Таблица FEDERATED состоит из двух элементов:

Выполняя запросы к таблице FEDERATED на локальном сервере, операции, которые обычно вставляли бы, обновляли или удаляли информацию из местного файла с данными вместо этого посланы в удаленный сервер для выполнения, где они обновляют файл с данными на удаленном сервере.

Базовая структура таблицы FEDERATED показана на рис. 17.1.

Рис. 17.1. Структура таблицы FEDERATED

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

  1. Механизм хранения просматривает каждый столбец таблицы FEDERATED и создает соответствующий запрос SQL, который относится к отдаленной таблице.

  2. Запрос посылают в удаленный сервер, используя MySQL client API.
  3. Удаленный сервер обрабатывает запрос, и локальный сервер получает любой результат, к которому запрос приводит (количество затронутых строк или набор результатов).
  4. Если запрос производит набор результатов, каждый столбец преобразован во внутренний формат механизма хранения, который может использоваться, чтобы вывести результат клиенту, который сделал оригинальное запрос.

Локальный сервер сообщает с использованием удаленного сервера MySQL C API. Это вызывает mysql_real_query() , чтобы послать запрос. Чтобы считать набор результатов, это использует mysql_store_result() и передает строки по одной, используя mysql_fetch_row().

17.8.2. Как составить таблицу FEDERATED

Чтобы создать таблицу FEDERATED, Вы должны следовать за этими шагами:

  1. Составьте таблицу на удаленном сервере. Альтернативно, обратите внимание на табличное определение существующей таблицы, возможно, используя SHOW CREATE TABLE.

  2. Составьте таблицу на локальном сервере с идентичным табличным определением, но с добавлением информации о соединении, которая соединяет местную таблицу с отдаленной.

Например, Вы могли бы составить следующую таблицу на удаленном сервере:

CREATE TABLE test_table (id INT(20) NOT NULL AUTO_INCREMENT,
                         name VARCHAR(32) NOT NULL DEFAULT '',
                         other INT(20) NOT NULL DEFAULT '0',
                         PRIMARY KEY (id), INDEX name (name),
                         INDEX other_key (other)) ENGINE=MyISAM
                         DEFAULT CHARSET=latin1;
Чтобы составить местную таблицу, которая будет объединенной с отдаленной таблицей, есть две доступные опции. Вы можете или составить местную таблицу и определить строку подключения (содержащую имя сервера, вход в систему и пароль), чтобы соединиться с отдаленной таблицей, используя CONNECTION, или Вы можете использовать существующее соединение, которое Вы ранее создали с использованием CREATE SERVER.

Когда Вы составляете местную таблицу, у нее должно быть определение, идентичное отдаленной таблице.

Вы можете улучшить исполнение таблицы FEDERATED добавлением индекса к таблице на узле. Оптимизация произойдет, потому что запрос, посланный в удаленный сервер, будет включать содержание предложения WHERE, посланного в удаленный сервер, и впоследствии выполнен в местном масштабе. Это уменьшает сетевой трафик, который иначе запросил бы всю таблицу от сервера для местной обработки.

17.8.2.1. Создание таблицы FEDERATED, используя CONNECTION

Чтобы использовать первый метод, Вы должны определить строку CONNECTION после типа механизма в CREATE TABLE. Например:

CREATE TABLE federated_table (id INT(20) NOT NULL AUTO_INCREMENT,
                              name VARCHAR(32) NOT NULL DEFAULT '',
                              other INT(20) NOT NULL DEFAULT '0',
                              PRIMARY KEY (id), INDEX name (name),
                              INDEX other_key (other)) ENGINE=FEDERATED
                              DEFAULT CHARSET=latin1
       CONNECTION='mysql://fed_user@remote_host:9306/federated/test_table';

CONNECTION заменяет COMMENT, используемый в некоторых предыдущих версиях MySQL.

Строка CONNECTION содержит информацию, запрошенную, чтобы соединиться с удаленным сервером, содержащим таблицу, которая будет использоваться, чтобы физически хранить данные. Строка подключения определяет имя сервера, параметры входа в систему, номер порта и информацию о базе данных/таблице. В примере отдаленная таблица находится на сервере remote_host, порт 9306. Имя и номер порта должны соответствовать имени хоста (или IP-адресу) и номеру порта отдаленного сервера MySQL, который Вы хотите использовать в качестве Вашей отдаленной таблицы.

Формат строки подключения:

scheme://user_name[:password]@
host_name[:port_num]/db_name/tbl_name
Здесь:

Типовые строки подключения:

CONNECTION='mysql://username:password@hostname:port/database/tablename'
CONNECTION='mysql://username@hostname/database/tablename'
CONNECTION='mysql://username:password@hostname/database/tablename'

17.8.2.2. Создание таблицы FEDERATED, используя CREATE SERVER

Если Вы создаете много таблиц FEDERATED на том же самом сервере, или если Вы хотите упростить процесс создания таблиц FEDERATED, Вы можете использовать CREATE SERVER, чтобы определить параметры соединения сервера, как Вы задали бы строку CONNECTION.

Формат CREATE SERVER:

CREATE SERVER server_name
       FOREIGN DATA WRAPPER wrapper_name
       OPTIONS (option [, option] ...)
server_name используется в строке подключения, создавая новую таблицу FEDERATED.

Например, чтобы создать соединение сервера, идентичное строке CONNECTION:

CONNECTION='mysql://fed_user@remote_host:9306/federated/test_table';
Вы использовали бы следующий запрос:
CREATE SERVER fedlink FOREIGN DATA WRAPPER mysql
       OPTIONS (USER 'fed_user', HOST 'remote_host', PORT 9306,
                DATABASE 'federated');
Чтобы создать таблицу FEDERATED, которая использует это соединение, Вы все еще используете ключевое слово CONNECTION, но определяете имя, которое Вы использовали в CREATE SERVER.
CREATE TABLE test_table (id INT(20) NOT NULL AUTO_INCREMENT,
                         name VARCHAR(32) NOT NULL DEFAULT '',
                         other INT(20) NOT NULL DEFAULT '0',
                         PRIMARY KEY (id), INDEX name (name),
                         INDEX other_key (other)) ENGINE=FEDERATED
                         DEFAULT CHARSET=latin1
                         CONNECTION='fedlink/test_table';
Имя соединения в этом примере содержит название соединения (fedlink) и название таблицы (test_table), отделенное наклонной чертой. Если Вы определяете только имя соединения без имени таблицы, имя местной таблицы используется вместо этого.

The CREATE SERVER принимает те же самые параметры, как строка CONNECTION. CREATE SERVER обновляет строки в таблице mysql.servers. См. следующую таблицу для информации о связи между параметрами в строке подключения, опциями в CREATE SERVER и и столбцами в таблице mysql.servers. Для ссылки формат строки CONNECTION следующий:

scheme://user_name[:password]@
host_name[:port_num]/db_name/tbl_name
ОписаниеСтрока CONNECTIONОпция CREATE SERVER Столбец mysql.servers
Схема соединенияscheme wrapper_nameWrapper
Отдаленный пользовательuser_name USERUsername
Отдаленный парольpassword PASSWORDPassword
Отдаленный узелhost_name HOSTHost
Отдаленный портport_num PORTPort
Отдаленная база данныхdb_name DATABASEDb

17.8.3. Примечания и подсказки о механизме хранения FEDERATED

Вы должны знать о следующих моментах, используя механизм хранения FEDERATED:

Следующие элементы указывают на особенности механизма хранения FEDERATED:

17.8.4. Ресурсы механизма хранения FEDERATED

Дополнительные ресурсы доступны для FEDERATED:

17.9. Механизм хранения EXAMPLE

Механизм хранения EXAMPLE это механизм, который ничего не делает. Его цель состоит в том, чтобы служить примером в исходном коде MySQL, который иллюстрирует, как начать писать новые механизмы хранения. Это имеет прежде всего интерес для разработчиков.

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

Исходные тексты механизма хранения EXAMPLE находятся в каталоге storage/example дистрибутива исходных текстов MySQL.

Когда Вы создаете EXAMPLE, никакие файлы не создаются. Никакие данные не могут храниться в таблицу. Извлечения возвращают пустой результат.

mysql> CREATE TABLE test (i INT) ENGINE = EXAMPLE;
Query OK, 0 rows affected (0.78 sec)

mysql> INSERT INTO test VALUES(1),(2),(3);
ERROR 1031 (HY000): Table storage engine for 'test' doesn't have this option

mysql> SELECT * FROM test;
Empty set (0.31 sec)
Механизм хранения EXAMPLE не поддерживает индексацию и разделение.

17.10. Другие механизмы хранения

Другие механизмы хранения могут быть доступными от третьих сторон и членов сообщества, которые использовали интерфейс Custom Storage Engine.

Сторонние механизмы не поддержаны MySQL. Для дополнительной информации, документации, инструкций по установке, сообщений об ошибках или для любой справки или помощи с этими механизмами, пожалуйста, свяжитесь с разработчиком механизма непосредственно.

Для получения дополнительной информации о развитии потребительского механизма хранения, который может использоваться с Pluggable Storage Engine Architecture, см. MySQL Internals: Writing a Custom Storage Engine.

17.11. Краткий обзор MySQL Storage Engine Architecture

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

Подключаемыя архитектура механизма хранения обеспечивает стандартный набор методов управления и поддержки, который распространен среди всех основных механизмов хранения. Механизмы самого хранения это компоненты сервера базы данных, которые фактически выполняют действия на основных данных, которые поддержаны на уровне физического сервера.

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

Программист приложения и DBA взаимодействуют с базой данных MySQL через Connector API и уровни служб, которые выше механизмов хранения. Если изменения приложения вызывают требования изменений механизма хранения, или чтобы один или более механизмов хранения были добавлены, чтобы поддержать новые потребности, никакие существенные изменения кодирования или процесса не нужны. Архитектура сервера MySQL экранирует приложение от основной сложности механизма хранения, представляя последовательный и удобный в работе API, который применяется через механизмы хранения.

17.11.1. Архитектура подключаемого механизма хранения

MySQL Server использует подключаемую архитектуру механизма хранения, которая позволяет механизмам хранения быть загруженными в сервер.

Включение механизма хранения

Прежде, чем механизм хранения сможет использоваться, совместно использованная библиотека плагина механизма хранения должна быть загружена в MySQL, используя INSTALL PLUGIN . Например, если плагин механизма EXAMPLE называется example и совместно используемую библиотеку называют ha_example.so, Вы загружаете это следующим запросм:

mysql> INSTALL PLUGIN example SONAME 'ha_example.so';
Чтобы установить подключаемый механизм хранения, файл должен быть расположен в каталоге плагинов MySQL, а пользователь, вызывающий INSTALL PLUGIN должен иметь привилегию INSERT для таблицы mysql.plugin.

Совместно используемая библиотека должна быть расположена в каталоге плагинов сервера MySQL, местоположение которого дано переменной plugin_dir.

Отключение механизма хранения

Чтобы отключить механизм хранения, используйте UNINSTALL PLUGIN:

mysql> UNINSTALL PLUGIN example;
Если Вы отключаете механизм хранения, который необходим существующим таблицам, те таблицы становятся недоступными, но будут все еще присутствовать на диске (где применимо). Гарантируйте, что нет никаких таблиц, использующих этот механизм хранения прежде, чем Вы отключите механизм хранения.

17.11.2. Общий уровень базы данных сервера

Подключаемый механизм хранения MySQL является компонентом в сервере базы данных MySQL, который ответственен за то, что выполняет фактические операции ввода/вывода для базы данных так же, как реализует определенные наборы функций, которые предназначаются для определенной потребности приложения. Главная выгода использования механизмов хранения: Вам поставляют только особенности, необходимые для особого приложения, поэтому у Вас есть меньше затрат с более эффективным конечным результатом

С технической точки зрения, каковы некоторые из уникальных компонентов инфраструктуры поддержки, которые находятся в механизме хранения? Некоторые из особенностей включают:

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