Глава 7. Типы таблиц MySQL

Содержание

7.1. Таблицы MyISAM

7.1.1. Пространство, необходимое для ключей

7.1.2. Форматы таблиц MyISAM

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

7.2. Таблицы MERGE

7.2.1. Проблемы при работе с таблицами MERGE

7.3. Таблицы ISAM

7.4. Таблицы HEAP

7.5. Таблицы InnoDB

7.5.1. Обзор таблиц InnoDB

7.5.2. Параметры запуска InnoDB

7.5.3. Создание табличной области InnoDB

7.5.4. Создание таблиц InnoDB

7.5.5. Добавление и удаление файлов данных и журналов InnoDB

7.5.6. Создание резервных копий и восстановление баз данных InnoDB

7.5.7. Перенесение базы данных InnoDB на другой компьютер

7.5.8. Транзакционная модель InnoDB

7.5.9. Реализация многовариантности

7.5.10. Структуры таблиц и индексов

7.5.11. Управление файловым пространством и дисковый ввод/вывод

7.5.12. Обработка ошибок

7.5.13. Ограничения для таблиц InnoDB

7.5.14. История изменений InnoDB

7.5.15. Контактная информация для получения данных по InnoDB

7.6. Таблицы BDB или BerkeleyDB

7.6.1. Обзор таблиц BDB

7.6.2. Установка BDB

7.6.3. Параметры запуска BDB

7.6.4. Характеристики таблиц BDB

7.6.5. Что нам нужно исправить в BDB в ближайшем будущем:

7.6.6. Операционные системы, поддерживаемые BDB

7.6.7. Ограничения таблиц BDB

7.6.8. Ошибки, которые могут возникнуть при использовании таблиц BDB

В MySQL версии 3.23.6 можно было выбирать из трех основных форматов таблиц (ISAM, HEAP и MyISAM). Более новые версии MySQL могут поддерживать дополнительные типы таблиц (InnoDB или BDB) - в зависимости от варианта установки.

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

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

Обратите внимание: если необходимо использовать таблицы InnoDB, при запуске следует указать параметр innodb_data_file_path. See Раздел 7.5.2, «Параметры запуска InnoDB».

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

Тем не менее, такое автоматическое изменение таблиц может сбить с толку новых пользователей MySQL. Мы планируем устранить эту проблему путем введения предупреждений в новом клиент-серверном протоколе в MySQL 4.1, которые будут выводиться при автоматическом изменении типов таблиц.

Преобразовывать таблицы из одного типа в другой можно при помощи оператора ALTER TABLE. See Раздел 6.5.4, «Синтаксис оператора ALTER TABLE».

Обратите внимание на то, что MySQL поддерживает два различных типа таблиц: транзакционные (InnoDB и BDB) и без поддержки транзакций (HEAP, ISAM, MERGE и MyISAM).

Преимущества транзакционных таблиц (Transaction-safe tables, TST):

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

• Можно сочетать несколько операторов и принимать все эти операторы одной командой COMMIT.

• Можно запустить команду ROLLBACK, чтобы отменить внесенные изменения (если работа не производится в режиме автоматической фиксации).

• Если произойдет сбой во время обновления, все изменения будут восстановлены (в нетранзакционных таблицах все внесенные изменения не могут быть отменены).

• Лучше обеспечивает параллелизм при одновременных обновлениях таблицы и чтении.

Обратите внимание, что для использования таблиц InnoDB вам как минимум следует указать опцию innodb_data_file_path. See Раздел 7.5.2, «Параметры запуска InnoDB».

Преимущества нетранзакционных таблиц (non-transaction-safe tables, NTST):

• Работать с ними намного быстрее, так как не выполняются дополнительные транзакции.

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

• Для обновлений используется меньше памяти.

В операторах можно сочетать таблицы TST и NTST, чтобы взять лучшее от каждого типа.

7.1. Таблицы MyISAM

7.1.1. Пространство, необходимое для ключей

7.1.2. Форматы таблиц MyISAM

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

Тип таблиц MyISAM принят по умолчанию в MySQL версии 3.23. Он основывается на коде ISAM и обладает в сравнении с ним большим количеством полезных дополнений.

Индекс хранится в файле с расширением .MYI (MYIndex), а данные - в файле с расширением .MYD (MYData). Таблицы MyISAM можно проверять/восстанавливать при помощи утилиты myisamchk. See Раздел 4.4.6.7, «Использование myisamchk для послеаварийного восстановления». Таблицы MyISAM можно сжимать при помощи команды myisampack, после чего они будут занимать намного меньше места. See Раздел 4.7.4, «myisampack, MySQL-генератор сжатых таблиц (только для чтения)».

Новшества, которыми обладает тип MyISAM:

• Флаг в файле MyISAM, указывающий, правильно была закрыта таблица или нет. В случае запуска mysqld с параметром --myisam-recover таблицы MyISAM будут автоматически проверяться и/или восстанавливаться при открытии, если таблица была закрыта неправильно.

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

• Поддержка больших файлов (63 бита) в файловых/операционных системах, которые поддерживают большие файлы.

• Хранение всех данных осуществляется с первым младшим байтом. Это делает данные независимыми от операционной системы. Единственное требование - в компьютере должны применяться дополненные до двух байтов целые числа со знаком (как и во всех компьютерах в последние 20 лет) и формат с плавающей единичной запятой IEEE (также использующийся в подавляющем большинстве серийных компьютеров). Единственными компьютерами, которые могут не поддерживать бинарную совместимость, являются встроенные системы (поскольку в них иногда применяются специальные процессоры). При хранении данных с первым младшим байтом не происходит снижения скорости. Обычно байты в строке таблицы не выровнены и нет большой разницы в том, как прочитать невыровненный байт - в прямой последовательности или в обратной. Фактическое время извлечения значения столбца также не критично по сравнению со временем выполнения остального кода.

• Все ключи номеров хранятся с первым старшим байтом, чтобы сжатие индексов было более эффективным.

• Внутренняя обработка столбца AUTO_INCREMENT. MyISAM автоматически обновляет его при выполнении команд INSERT/UPDATE. Значение AUTO_INCREMENT может быть обнулено оператором myisamchk. После этого столбец AUTO_INCREMENT будет быстрее (по крайней мере на 10%) и старые номера не будут повторно использоваться, как со старым ISAM. Обратите внимание: когда AUTO_INCREMENT задан в конце составного ключа, старое поведение все еще сохраняется.

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

• Столбцы BLOB и TEXT могут быть проиндексированы.

• В индексных столбцах разрешены значения NULL. Они занимают 0-1 байта на ключ.

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

• По умолчанию в таблице может быть не более 32 ключей. Это значение можно увеличить до 64 без повторной компиляции myisamchk.

• myisamchk будет отмечать таблицы как проверенные, если они запускаются с параметром --update-state. myisamchk --fast будет проверять только те таблицы, в которых отсутствует данная пометка.

• myisamchk -a сохраняет статистические данные по частям ключа (не только для ключей целиком, как в ISAM).

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

• myisampack может упаковывать столбцы BLOB и VARCHAR.

• Можно поместить файл данных и файл индексов в разные каталоги, чтобы увеличить скорость (с параметром DATA/INDEX DIRECTORY="path" для CREATE TABLE). See Раздел 6.5.3, «Синтаксис оператора CREATE TABLE».

MyISAM также поддерживает следующие функции, которые можно будет использовать в MySQL в ближайшем будущем:

• Поддержка типа VARCHAR; столбец VARCHAR начинается с длины, которая хранится в 2 байтах.

• Таблицы с VARCHAR могут иметь фиксированную или динамическую длину записей.

• VARCHAR и CHAR могут быть до 64 Кб длиной. У всех ключевых сегментов есть свои собственные определения языка. Это позволяет задавать в MySQL различные определения языка для каждого столбца.

• Для UNIQUE может использоваться вычисленный хэш-индекс. Это позволяет использовать UNIQUE с любым сочетанием столбцов в таблице (тем не менее, нельзя производить поиск по вычисленному UNIQUE индексу).

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

Приведенные ниже параметры mysqld могут использоваться для изменения поведения таблиц MyISAM. See Раздел 4.5.6.4, «SHOW VARIABLES».

Автоматическое восстановление активизируется при запуске mysqld с параметром --myisam-recover=# (see Раздел 4.1.1, «Параметры командной строки mysqld»). Когда таблица открывается, производится проверка, не помечена ли она как сбойная, не равна ли переменная счетчика открытий таблицы нулю (0) и не производится ли запуск с параметром --skip-external-locking. Если хотя бы одно из этих условий выполняется, произойдет следующее:

• Будет произведена проверка таблицы на наличие ошибок;

• Если обнаружится ошибка, будет произведена попытка быстрого восстановления (с сортировкой и без повторного создания файла данных) таблицы;

• Если восстановление не удалось из-за ошибки в файле данных (например, ошибка дублирующегося ключа), будет произведена вторая попытка, но на этот раз с повторным созданием файла данных.

• Если восстановление не удастся, будет произведена еще одна попытка с применением старого метода восстановления (запись по строкам без сортировки), который обеспечивает устранение ошибок любого типа с использованием незначительных ресурсов диска.

Если не удается восстановить все строки из предыдущего выполненного оператора, и не был указан параметр FORCE для myisam-recover, автоматическое восстановление будет отменено со следующей ошибкой в файле ошибок:

Error: Couldn't repair table: test.g00pages

Если в этом случае был указан параметр FORCE, вместо вышеуказанного сообщения в файле ошибок будет присутствовать следующее предупреждение:

Warning: Found 344 of 354 rows when repairing ./test/g00pages

Обратите внимание: если запустить автоматическое восстановление с параметром BACKUP, необходимо установить скрипт cron, который автоматически перемещает файлы с именами tablename-datetime.BAK из каталогов базы данных на носитель резервного копирования.

See Раздел 4.1.1, «Параметры командной строки mysqld».

7.1.1. Пространство, необходимое для ключей

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

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

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

7.1.2. Форматы таблиц MyISAM

7.1.2.1. Характеристики статических таблиц (с фиксированной длиной)

7.1.2.2. Характеристики динамических таблиц

7.1.2.3. Характеристики сжатых таблиц

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

При использовании с таблицами команд CREATE или ALTER для таблиц, у которых нет форсированной настройки BLOB, можно задать формат DYNAMIC или FIXED с параметром таблицы ROW_FORMAT=#. В будущем можно будет сжимать/разжимать таблицы, указывая ROW_FORMAT=compressed | default для ALTER TABLE. See Раздел 6.5.3, «Синтаксис оператора CREATE TABLE».

7.1.2.1. Характеристики статических таблиц (с фиксированной длиной)

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

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

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

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

• Все столбцы CHAR, NUMERIC и DECIMAL расширены пробелами до ширины столбца;

• Очень быстрые;

• Легко кэшируются;

• Легко восстанавливаются после сбоя, так как записи расположены в фиксированных позициях;

• Не нуждаются в реорганизации (при помощи myisamchk), кроме случаев, когда удаляется большое количество записей и необходимо вернуть дисковое пространство операционной системе.

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

7.1.2.2. Характеристики динамических таблиц

Данный формат используется для таблиц, которые содержат столбцы VARCHAR, BLOB или TEXT, а также если таблица была создана с параметром ROW_FORMAT=dynamic.

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

Чтобы произвести дефрагментацию таблицы, можно воспользоваться командами OPTIMIZE table или myisamchk. Если у вас есть статические данные, которые часто считываются/изменяются в некоторых столбцах VARCHAR или BLOB одной и той же таблицы, во избежание фрагментации эти динамические столбцы лучше переместить в другие таблицы. Свойства динамических таблиц следующие:

• Все столбцы со строками являются динамическими (кроме тех, у которых длина меньше 4).

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

• Обычно такие таблицы занимают намного меньше дискового пространства, чем таблицы с фиксированной длиной.

• Для всех записей используется ровно столько места, сколько необходимо. Если размер записи увеличивается, она разделяется на несколько частей - по мере необходимости. Это приводит к фрагментации записей.

• Если в строку добавляется информация, превышающая длину строки, строка будет фрагментирована. В этом случае для увеличения производительности можно время от времени запускать команду myisamchk -r. Чтобы получить статистические данные, воспользуйтесь командой myisamchk -ei tbl_name.

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

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

  3
  + (число столбцов+ 7) / 8
  + (число столбцов char)
  + размер числовых столбцов в упакованном виде
  + длина строк
  + (число столбцов NULL + 7) / 8
  

  На каждую ссылку добавляется по 6 байтов. Динамические записи связываются при каждом увеличении записи во время обновления. Каждая новая ссылка занимает по крайней мере 20 байтов, поэтому следующее увеличение может произойти либо по этой же ссылке; либо по другой, если не хватит места. Количество ссылок можно проверить при помощи команды myisamchk -ed. Все ссылки можно удалить при помощи команды myisamchk -r.

7.1.2.3. Характеристики сжатых таблиц

Таблицы этого тип предназначены только для чтения. Они генерируются при помощи дополнительного инструмента myisampack (pack_isam для таблиц ISAM):

• Все дистрибутивы MySQL, даже выпущенные до предоставления общедоступной лицензии MySQL, могут читать таблицы, которые были сжаты при помощи myisampack.

• Сжатые таблицы занимают очень мало дискового пространства; таким образом при применении данного типа значительно снижается использование дискового пространства. Это полезно при работе с медленными дисками (такими как компакт-диски).

• Каждая запись сжимается отдельно (незначительные издержки при доступе). Заголовки у записей фиксированные (1-3 байта), в зависимости от самой большой записи в таблице. Все столбцы сжимаются по-разному. Ниже приведено описание некоторых типов сжатия:

  • Обычно для каждого столбца используются разные таблицы Хаффмана.

  • Сжимаются пробелы суффикса.

  • Сжимаются пробелы префикса.

  • Для хранения чисел со значением 0 отводится 1 бит.

  • Если у значений в целочисленном столбце небольшой диапазон, столбец сохраняется с использованием минимального по размерам возможного типа. Например, столбец BIGINT (8 байт) может быть сохранен как столбец TINYINT (1 байт) если все значения находятся в диапазоне от 0 до 255.

  • Если в столбце содержится небольшое множество возможных значений, тип столбца преобразовывается в ENUM.

  • Столбец может содержать сочетание указанных выше сжатий.

• Для таблиц этого типа возможна обработка записей с фиксированной или динамической длиной.

• Таблицы данного типа могут быть распакованы при помощи команды myisamchk.

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

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

7.1.3.2. Clients is using or hasn't closed the table properly

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

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

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

• Процесс mysqld уничтожен во время осуществления записи;

• Неожиданное отключение компьютера (например, если выключилось электропитание);

• Ошибка аппаратного обеспечения;

• Использование внешней программы (например myisamchk) на открытой таблице.

• Ошибка программного обеспечения в коде MySQL или MyISAM.

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

• Во время выбора данных из таблицы выдается ошибка Incorrect key file for table: '...'. Try to repair it.

• Запросы не находят в таблице строки или выдают неполные данные.

Проверить состояние таблицы можно при помощи команды CHECK TABLE. См. раздел See Раздел 4.4.4, «Синтаксис CHECK TABLE ».

Для восстановления поврежденного файла можно применить команду REPAIR TABLE. See Раздел 4.4.5, «Синтаксис REPAIR TABLE ». Таблицу можно восстановить и в случае, когда не запущен mysqld, при помощи команды myisamchk. See Раздел 4.4.6.1, «Синтаксис запуска myisamchk».

Если таблицы повреждены значительно, необходимо выяснить причину произошедшего! See Раздел A.4.1, «Что делать, если работа MySQL сопровождается постоянными сбоями».

Сначала следует определить, послужил ли причиной повреждения таблицы сбой mysqld (это можно легко проверить, просмотрев последние строки restarted mysqld в файле ошибок mysqld). Если дело не в этом, то необходимо составить подробное описание произошедшего. See Раздел E.1.6, «Создание контрольного примера при повреждении таблиц».

7.1.3.2. Clients is using or hasn't closed the table properly

Клиенты неправильно используют таблицу или не закрыли ее надлежащим образом

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

Если при выполнении команд CHECK TABLE или myisamchk выдается следующая ошибка:

# clients is using or hasn't closed the table properly

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

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

• Во время первого обновления таблицы в MySQL значение счетчика в заголовках индексных файлов увеличивается.

• Во время следующих обновлений значение счетчика не изменяется.

• После закрытия последней записи таблицы (после применения команды FLUSH или из-за отсутствия места в кэше таблицы) значение счетчика уменьшается, если в таблицу были внесены изменения.

• Если производится проверка таблицы, или проверка показывает, что все в порядке, счетчик устанавливается в значение 0.

• Чтобы избежать пересечения с другими процессами, которые могут проверять таблицу, при закрытии значение счетчика не уменьшается, если счетчик установлен в значение 0.

Иначе говоря, синхронность может быть нарушена следующим образом:

• Таблицы MyISAM копируются без команд LOCK и FLUSH TABLES.

• Между обновлением и последним закрытием произошел сбой MySQL (обратите внимание: с таблицей все может быть в порядке, так как MySQL документирует все изменения между выполнением каждого из операторов).

• Кто-то применил команду myisamchk --recover или myisamchk --update-state к таблице, которая в данный момент использовалась mysqld.

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

7.2. Таблицы MERGE

7.2.1. Проблемы при работе с таблицами MERGE

Таблицы MERGE (объединение) являются новшеством версии MySQL 3.23.25. В настоящее время код находится еще на стадии разработки, но, тем не менее, должен быть достаточно стабилен.

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

Обратите внимание на то, что команда DELETE FROM merge_table без параметра WHERE очищает только распределение для таблицы, но ничего не удаляет из распределенных таблиц (мы планируем исправить это в версии 4.1).

Под идентичными таблицами подразумеваются таблицы, созданные с одинаковой структурой и ключами. Нельзя объединять таблицы, в которых столбцы сжаты разными методами или не совпадают, либо ключи расположены в другом порядке. Тем не менее, некоторые таблицы можно сжимать при помощи команды myisampack. See Раздел 4.7.4, «myisampack, MySQL-генератор сжатых таблиц (только для чтения)».

При создании таблицы MERGE будут образованы файлы определений таблиц .frm и списка таблиц .MRG. Файл .MRG содержит список индексных файлов (файлы .MYI), работа с которыми должна осуществляться как с единым файлом. Все используемые таблицы должны размещаться в той же базе данных, что и таблица MERGE.

На данный момент по отношению к таблицам, которые необходимо преобразовать в таблицу MERGE,необходимо обладать привилегиями SELECT, UPDATE и DELETE.

Ниже перечислены возможности, которые обеспечивают таблицы MERGE:

• Простое управление набором файлов журналов. Например, можно поместить данные за различные месяцы в отдельные файлы, сжать некоторые из них при помощи myisampack, а затем создать таблицу MERGE, чтобы использовать их как одну таблицу.

• Увеличение скорости работы. Большую таблицу можно разделить по некоторому критерию, а затем поместить различные части таблицы на разные диски. В этом случае таблица MERGE может обрабатываться намного быстрее, чем обычная большая таблица (можно, конечно, воспользоваться дисковым массивом RAID, чтобы получить те же преимущества).

• Более эффективный поиск. Если точно известно, что вы ищете, можно производить поиск по определенным запросам только в одной из составляющих таблицу MERGE таблиц, одновременно используя таблицу MERGE для других запросов. Можно даже иметь несколько активных таблиц MERGE (возможно, с перекрывающимися файлами).

• Более простое восстановление. Гораздо легче восстановить отдельные файлы, которые преобразованы в файл MERGE, чем пытаться восстановить действительно большой файл.

• Быстрая обработка большого количества файлов как одного. Для таблицы MERGE используются индексы отдельных таблиц; поддерживать для нее один большой индекс нет необходимости. Благодаря этому создание или изменение таблиц MERGE осуществляется ОЧЕНЬ быстро. Обратите внимание на то, что при создании таблицы MERGE необходимо указывать определения ключей!

• Если требуется объединить несколько таблиц в одну большую таблицу по требованию или при формировании, лучше создать для них по требованию таблицу MERGE. Это намного быстрее и позволит сэкономить дисковое пространство.

• Таблицы MERGE позволяют обходить ограничения на размер файлов в операционных системах.

• Можно создать псевдоним/синоним для таблицы - для этого нужно просто применить MERGE к одной таблице. Заметного падения производительности при этом наблюдаться не будет (только пара непрямых вызовов и вызовы memcpy() при каждом чтении).

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

• Для создания таблицы MERGE можно использовать только идентичные таблицы MyISAM.

• Не работает команда REPLACE.

• Для таблиц MERGE используется больше дескрипторов файлов. Если применяется таблица MERGE, преобразованная из более чем 10 таблиц, к которым получают доступ 10 пользователей, то используется 10*10 + 10 дескрипторов файлов (10 файлов данных для 10 пользователей и 10 общих индексных файлов).

• Ключи считываются медленнее. При чтении ключа обработчику MERGE необходимо прочитать все базовые таблицы, чтобы выяснить, какая из них больше всего соответствует указанному ключу. Если после этого выполнить команду ``читать следующий'', то обработчик объединенной таблицы должен будет просмотреть буферы чтения, чтобы найти следующий ключ. Только по завершении использования одного буфера ключей обработчику понадобится прочитать следующий блок ключей. В связи с этим ключи MERGE дают большое замедление при поиске eq_ref, однако не такое значительное при поиске ref. See Раздел 5.2.1, «Синтаксис оператора EXPLAIN (получение информации о SELECT)».

• Нельзя выполнять команды DROP TABLE, ALTER TABLE, DELETE FROM table_name без оператора WHERE REPAIR TABLE, TRUNCATE TABLE, OPTIMIZE TABLE, или ANALYZE TABLE по отношению к таблицам, которые размещены в таблице MERGE и открыты. Если это сделать, в таблице MERGE останутся ссылки на исходную таблицу, и полученные результаты будут совершенно непредсказуемыми. Самый легкий путь обойти эти трудности - выполнить комманду FLUSH TABLES. Это удостоверит, что ни одна таблица MERGE не будет открытой.

При создании таблицы MERGE необходимо указать при помощи UNION(list-of-tables), какие таблицы требуется использовать как одну. В случае необходимости, если требуется производить вставку в таблицу MERGE в первую или в последнюю таблицу в списке UNION, можно задать INSERT_METHOD. Если не указать INSERT_METHOD или выбрать NO, то все команды INSERT для таблицы MERGE будут выдавать ошибку.

В приведенном ниже примере показано, как использовать таблицы MERGE:

CREATE TABLE t1 (a INT AUTO_INCREMENT PRIMARY KEY, message CHAR(20));
CREATE TABLE t2 (a INT AUTO_INCREMENT PRIMARY KEY, message CHAR(20));
INSERT INTO t1 (message) VALUES ("Testing"),("table"),("t1");
INSERT INTO t2 (message) VALUES ("Testing"),("table"),("t2");
CREATE TABLE total (a INT AUTO_INCREMENT PRIMARY KEY, message CHAR(20))
TYPE=MERGE UNION=(t1,t2) INSERT_METHOD=LAST;

Кроме того, можно управлять файлом .MRG, находясь за пределами сервера MySQL:

shell> cd /mysql-data-directory/current-database
shell> ls -1 t1.MYI t2.MYI > total.MRG
shell> mysqladmin flush-tables

Теперь можно выполнять следующие действия:

mysql> SELECT * FROM total;
+---+---------+
| a | message |
+---+---------+
| 1 | Testing |
| 2 | table   |
| 3 | t1      |
| 1 | Testing |
| 2 | table   |
| 3 | t2      |
+---+---------+

Обратите внимание на то, что столбец a, хотя и объявлен как PRIMARY KEY, не является уникальным, так как таблица MERGE не может обеспечивать уникальность для всех таблиц MyISAM.

Чтобы повторно преобразовать таблицу MERGE, можно выбрать один из следующих вариантов:

• Применить к таблице команду DROP и создать ее повторно

• Воспользоваться командой ALTER TABLE table_name UNION(...)

• Изменить файл .MRG и выполнить команду FLUSH TABLE над таблицей MERGE и всеми базовыми таблицами, чтобы обработчик прочитал новый файл определения.

7.2.1. Проблемы при работе с таблицами MERGE

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

• Для таблицы MERGE не могут поддерживаться ограничения UNIQUE по всей таблице. При выполнении команды INSERT данные помещаются в первую или последнюю таблицу (в соответствии с INSERT_METHOD=xxx) и для этой таблицы MyISAM обеспечивается однозначность данных, но ей ничего не известно об остальных таблицах MyISAM.

• Команда DELETE FROM merge_table без оператора WHERE очищает только распределение для таблицы, ничего не удаляя из преобразованных таблиц.

• Использование команды RENAME TABLE над активной таблицей MERGE может привести к повреждению таблицы. Эта ошибка будет исправлена в MySQL 4.0.x.

• При создании таблицы типа MERGE не проверяется совместимость типов базовых таблиц. Создав таблицу MERGE на основе несовместимых типов, вы можете столкнуться с непредсказуемыми проблемами.

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

• Оптимизатор диапазона пока не может эффективно использовать таблицу MERGE, в связи с чем иногда возникают неоптимальные соединения. Это будет исправлено в MySQL 4.0.x.

Команда DROP TABLE над таблицей, преобразованной в таблицу MERGE, не будет работать под Windows, так как обработчик MERGE скрывает распределение таблиц от верхнего уровня MySQL. Поскольку в Windows не разрешается удалять открытые файлы, сначала необходимо сбросить на диск все таблицы MERGE (при помощи команды FLUSH TABLES) или удалить таблицу MERGE перед тем, как удалить таблицу. Эту ошибку мы планируем исправить одновременно с введением VIEW.

7.3. Таблицы ISAM

В MySQL пока еще можно применять и устаревший тип таблиц ISAM. В ближайшем времени этот тип будет исключен (возможно, в MySQL 5.0), так как MyISAM является улучшенной реализацией тех же возможностей. В таблицах ISAM используется индекс B-tree. Индекс хранится в файле с расширением .ISM, а данные - в файле с расширением .ISD. Таблицы ISAM можно проверять/восстанавливать при помощи утилиты isamchk (see Раздел 7.1, «Таблицы MyISAM»).

Ниже перечислены свойства таблиц ISAM:

• Ключи со сжатой и фиксированной длиной

• Фиксированная и динамическая длина записи

• 16 ключей с 16 частями ключей/ключами

• Максимальная длина ключа 256 (по умолчанию)

• Данные хранятся в машинном формате; благодаря этому обеспечивается скорость, но возникает зависимость от компьютера/ОС.

Большинство параметров таблиц MyISAM также соответствуют таблицам ISAM. See Раздел 7.1, «Таблицы MyISAM». Ниже перечислены основные отличия таблиц ISAM от MyISAM:

• Таблицы ISAM не являются переносимыми в двоичном виде с одной ОС/платформы на другую;

• Невозможна работа с таблицами > 4Гб.

• В строках поддерживается только сжатие префикса.

• Ограничения по маленьким ключам.

• Динамические таблицы больше фрагментируются.

• Таблицы сжимаются при помощи pack_isam, а не при помощи myisampack.

Если вы хотите преобразовать таблицу ISAM в таблицу MyISAM, чтобы иметь возможность работать с такими утилитами, как mysqlcheck, воспользуйтесь оператором ALTER TABLE:

mysql> ALTER TABLE tbl_name TYPE = MYISAM;

Встроенные версии MySQL не поддерживают таблицы ISAM.

7.4. Таблицы HEAP

Для HEAP-таблиц используются хэш-индексы; эти таблицы хранятся в памяти. Благодаря этому обработка их осуществляется очень быстро, однако в случае сбоя MySQL будут утрачены все данные, которые в них хранились. Тип HEAP очень хорошо подходит для временных таблиц!

Для внутренних HEAP-таблиц в MySQL используется 100%-ное динамическое хэширование без областей переполнения; дополнительное пространство для свободных списков не требуется. Отсутствуют при использовании HEAP-таблиц и проблемы с командами удаления и вставки, которые часто применяются в хэшированных таблицах:

mysql> CREATE TABLE test TYPE=HEAP SELECT ip,SUM(downloads) AS down
    -> FROM log_table GROUP BY ip;
mysql> SELECT COUNT(ip),AVG(down) FROM test;
mysql> DROP TABLE test;

При использовании HEAP-таблиц необходимо обращать внимание на следующие моменты:

• Необходимо всегда указывать параметр MAX_ROWS в операторе CREATE, чтобы случайным образом не занять всю память.

• Индексы будут использоваться только с = и <=> (но ОЧЕНЬ быстрые).

• В HEAP-таблицах для поиска строки могут использоваться только полные ключи, в то время как для таблиц MyISAM при поиске строк может применяться любой префикс ключа.

• Для HEAP-таблиц используется формат с фиксированной длиной записи.

• Для HEAP-таблиц не поддерживаются столбцы формата BLOB/TEXT.

• Для HEAP-таблиц не поддерживаются столбцы формата AUTO_INCREMENT.

• До версии 4.0.2 для HEAP-таблиц не поддерживаются индексы в столбцах формата NULL.

• В HEAP-таблицах могут встречаться совпадающие ключи (что не является нормой для хэшированных таблиц).

• HEAP-таблицы используются совместно всеми клиентами (как и все другие таблицы).

• Нельзя производить поиск следующей записи в порядке следования (т.е. использовать индекс в команде ORDER BY).

• Данные HEAP-таблиц расположены в маленьких блоках. Таблицы на 100% являются динамическими (при вставке). Нет необходимости ни в областях переполнения, ни в дополнительных ключах. Удаленные строки помещаются в связанный список и используются при вставке в таблицу новых данных.

• Следует позаботиться о том, чтобы имелось достаточное количество дополнительной памяти для всех HEAP-таблиц, которые будут использоваться одновременно,.

• Чтобы освободить память, необходимо запустить команду DELETE FROM heap_table, TRUNCATE heap_table или DROP TABLE heap_table.

• MySQL не может подсчитать, сколько строк находится между двумя значениями (используется оптимизатором диапазонов для выбора используемого индекса). Это может повлиять на некоторые запросы, если преобразовать таблицу MyISAM в формат HEAP.

• При создании размер таблицы HEAP не может превышать max_heap_table_size; это сделано для того, чтобы обеспечить защиту от случайных неквалифицированных действий.

Количество памяти, необходимой для одной строки в HEAP-таблице, вычисляется следующим образом:

SUM_OVER_ALL_KEYS(max_length_of_key + sizeof(char*) * 2)
+ ALIGN(length_of_row+1, sizeof(char*))

sizeof(char*) составляет 4 на 32-разрядных компьютерах и 8 - на 64-разрядных.

7.5. Таблицы InnoDB

7.5.1. Обзор таблиц InnoDB

7.5.2. Параметры запуска InnoDB

7.5.3. Создание табличной области InnoDB

7.5.4. Создание таблиц InnoDB

7.5.5. Добавление и удаление файлов данных и журналов InnoDB

7.5.6. Создание резервных копий и восстановление баз данных InnoDB

7.5.7. Перенесение базы данных InnoDB на другой компьютер

7.5.8. Транзакционная модель InnoDB

7.5.9. Реализация многовариантности

7.5.10. Структуры таблиц и индексов

7.5.11. Управление файловым пространством и дисковый ввод/вывод

7.5.12. Обработка ошибок

7.5.13. Ограничения для таблиц InnoDB

7.5.14. История изменений InnoDB

7.5.15. Контактная информация для получения данных по InnoDB

7.5.1. Обзор таблиц InnoDB

Таблицы InnoDB в MySQL снабжены обработчиком таблиц, обеспечивающим безопасные транзакции (уровня ACID) с возможностями фиксации транзакции, отката и восстановления после сбоя. Для таблиц InnoDB осуществляется блокировка на уровне строки, а также используется метод чтения без блокировок в команде SELECT (наподобие применяющегося в Oracle). Перечисленные функции позволяют улучшить взаимную совместимость и повысить производительность в многопользовательском режиме. В InnoDB нет необходимости в расширении блокировки, так как блоки строк в InnoDB занимают очень мало места. Для таблиц InnoDB поддерживаются ограничивающие условия FOREIGN KEY.

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

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

Свежую информацию по InnoDB можно найти на http://www.innodb.com/. Здесь же находится последняя версия руководства по InnoDB. Кроме того, можно заказать коммерческие лицензии и поддержку для InnoDB.

В настоящий момент (октябрь 2001 года) таблицы InnoDB применяются на нескольких больших сайтах баз данных, для которых важна высокая производительность. Так, таблицы InnoDB используются на популярном сайте новостей Slashdot.org. Формат InnoDB применяется для хранения более 1Тб данных компании Mytrix, Inc; можно привести пример еще одного сайта, где при помощи при помощи InnoDB обрабатывается средняя нагрузка объемом в 800 вставок/обновлений в секунду.

Таблицы InnoDB входят в дистрибутив исходных текстов MySQL, начиная с версии 3.23.34a; они активизированы в исполняемом коде MySQL -Max. Для Windows исполняемые коды -Max находятся в стандартном дистрибутиве.

Если вы загрузили исполняемую версию MySQL, которая включает поддержку InnoDB, следует просто выполнить инструкции руководства MySQL по установке исполняемой версии MySQL. В случае, если у вас уже установлен MySQL-3.23, проще всего установить MySQL -Max, чтобы заменить исполняемый файл mysqld соответствующим файлом из дистрибутива -Max. Различными в MySQL и MySQL -Max являются только исполняемые файлы сервера. См. разделы Раздел 2.2.8, «Установка бинарного дистрибутива MySQL» и See Раздел 4.7.5, «mysqld-max, расширенный сервер mysqld».

Чтобы произвести компиляцию MySQL с поддержкой InnoDB, загрузите MySQL-3.23.34a или более новую версию с http://www.mysql.com/ и настройте MySQL при помощи параметра --with-innodb. См. раздел руководства MySQL по установке дистрибутива исходного кода MySQL, See Раздел 2.3, «Установка исходного дистрибутива MySQL».

cd /path/to/source/of/mysql-3.23.37
./configure --with-innodb

Чтобы использовать InnoDB, необходимо указать параметры запуска InnoDB в своем файле my.cnf или my.ini. Самый простой способ внести изменения - добавить в раздел [mysqld] строку

innodb_data_file_path=ibdata:30M

Однако чтобы добиться высокой скорости работы, лучше указать рекомендуемые параметры. See Раздел 7.5.2, «Параметры запуска InnoDB».

InnoDB распространяется на условиях общедоступной лицензии версии 2 (от июня 1991 года). В дистрибутиве исходного кода MySQL InnoDB находится в подкаталоге innobase.

7.5.2. Параметры запуска InnoDB

Чтобы использовать таблицы InnoDB в MySQL-Max-3.23, НЕОБХОДИМО задать параметры конфигурации в разделе [mysqld] файла конфигурации my.cnf или в файле параметров Windows my.ini.

В версии 3.23 как минимум необходимо указать имя и размер файлов данных в innodb_data_file_path. Если вы не указали innodb_data_home_dir в my.cnf по умолчанию эти файлы создаются в директории данных MySQL. Если вы указали innodb_data_home_dir как пустую строку, то вы должны указать полный путь к вашим файлам данным в innodb_data_file_path. В MySQL 4.0 не требуется задавать даже innodb_data_file_path: по умолчанию для него создается автоматически увеличивающийся файл размером в 10 Мб с именем ibdata1 в каталоге datadir MySQL. (в MySQL-4.0.0 и 4.0.1 размер файла данных составляет 64 Мб и он не является автоматически увеличивающимся).

Если вы не хотите использовать InnoDB таблицы, вы можете добавить опцию skip-innodb в конфигурационный файл MySQL.

Однако для того, чтобы получить высокую производительность, НЕОБХОДИМО явно задать параметры InnoDB, перечисленные в следующих примерах.

Начиная с версий 3.23.50 и 4.0.2 для InnoDB имеется возможность задавать последний файл данных в innodb_data_file_path как автоматически увеличивающийся. В этом случае для innodb_data_file_path используется следующий синтаксис:

pathtodatafile:sizespecification;pathtodatafile:sizespecification;...
... ;pathtodatafile:sizespecification[:autoextend[:max:sizespecification]]

Если последний файл данных указан с параметром автоматического увеличения, то в случае нехватки места для табличной области InnoDB будет увеличивать последний файл данных; приращение файла каждый раз составляет 8 Мб. Например, синтаксис:

innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:100M:autoextend

указывает InnoDB создать один файл данных с начальным размером 100 Мб, который будет увеличиваться на 8 Мб каждый раз, когда не будет хватать места. Если текущий диск окажется заполненным, можно, к примеру, добавить еще один файл данных на другой диск. При задании размера автоматически увеличивающегося файла ibdata1 следует округлить его текущий размер до ближайшего числа, кратного 1024 * 1024 байтам (= 1 Мб), и явно указать округленный размер ibdata1 в innodb_data_file_path. После этой записи можно добавить еще один файл данных:

innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend

Следует соблюдать осторожность при работе в файловых системах, в которых установлено ограничение на размер файла в 2 Гб! Максимальный для данной операционной системы размер файла InnoDB не известен. В таком случае желательно указать максимальный размер файла данных:

innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:100M:autoextend:max:2000M

Простой пример файла my.cnf. Предположим, что у вас есть компьютер с 128 Мб ОЗУ и одним жестким диском. Ниже приведены примеры возможных параметров конфигурации в my.cnf или my.ini для InnoDB. Мы предполагаем что у вас запущен MySQL-Max-3.23.50 и выше или MySQL-4.0.2 и выше. Этот пример подходит для большинства пользователей работающих под Unix и Windows, которые не хотят располагать файлы данных и журнальные файлы на различных дисках. В этом примере создается автоматически увеличивающийся файл ibdata1 и два журнальных файла ib_logfile0 и ib_logfile1 в в директории данных MySQL (обычно /mysql/data). Небольшой архивный журнальный файл InnoDB ib_arch_log_0000000000 также располагается в каталоге datadir:

[mysqld]
# Сюда  можно  добавить  другие  опции MySQL
# ...
#
# Файлы  данных  должны  иметь  достаточно
# места  для  сохранения  ваших  данных  и
# индексов. Убедитесь что у вас достаточно 
# свободного места на диске.
innodb_data_file_path = ibdata1:10M:autoextend
# Размер  буферного  пула  следует  задавать
# как 50 - 80% памяти  компьютера
set-variable = innodb_buffer_pool_size=70M
set-variable = innodb_additional_mem_pool_size=10M
# Размер  файла  журналов  должен  составлять
# около 25% от  размера  буферного  пула
set-variable = innodb_log_file_size=20M
set-variable = innodb_log_buffer_size=8M
# Если  допустима  потеря  некоторых
# последних  транзакций, установите
# flush_log_в_trx_commit в 0
innodb_flush_log_at_trx_commit=1

Убедитесь, что MySQL server имеет права создавать файлы в datadir.

Не забывайте, что в некоторых файловых системах существует ограничение в 2 Гб на размер файла данных! Общий размер файлов журналов должен быть меньше 4 Гб, а общий размер файлов данных - больше или равен 10Мб.

При первом создании базы данных InnoDB лучше всего запустить сервер MySQL из командной строки. Тогда на экран будет выводиться информация о создании базы данных и вы сможете увидеть, что происходит. Смотрите следующий раздел, в котором описано, на что должна быть похожа выводимая информация. Например, в Windows можно запустить mysqld-max.exe с параметрами:

your-path-to-mysqld