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

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

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

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

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

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

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

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

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

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

Проверить состояние таблицы можно при помощи команды 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, «Создание контрольного примера при повреждении таблиц».

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

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

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

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

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

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

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

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

Если InnoDB выдает ошибку операционной системы во время операции с файлом, то причиной возникшей проблемы, как правило, является одна из следующих:

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

В InnoDB отсутствует специальная оптимизация создания отдельных индексов. Таким образом, этот формат не обеспечивает экспорта и импорта таблиц с последующим созданием индексов. Самый быстрый способ преобразовать таблицу в формат InnoDB - напрямую вставить данные в таблицу InnoDB, воспользовавшись командой ALTER TABLE ... TYPE=INNODB, или создать пустую таблицу InnoDB с такой же структурой и вставить строки при помощи команды INSERT INTO ... SELECT * FROM ....

Чтобы лучше контролировать процесс вставки, большие таблицы желательно вставлять по частям:

INSERT INTO newtable SELECT * FROM oldtable
   WHERE yourkey > something AND yourkey <= somethingelse;

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

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

Убедитесь, что у вас достаточно свободного пространства для табличной области: таблицы InnoDB занимают намного больше места, чем таблицы MyISAM. Если во время выполнения команды ALTER TABLE будет исчерпано свободное дисковое пространство, начнется выполнение отката, и это может занять несколько часов, если диск заполнен. Во время вставок для таблицы InnoDB используется буфер вставки, чтобы произвести объединение вторичных индексных записей с индексными таблицами при помощи групповых операций. Это позволяет значительно снизить интенсивность дисковых операций ввода/вывода. При откате такой механизм не используется, поэтому откат может занять в 30 раз больше времени, чем вставка.

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

Начиная с версии 3.23.43b, в InnoDB включены ограничения внешних ключей. InnoDB - первый формат таблиц MySQL, который обеспечивает возможность задавать ограничения внешнего ключа, чтобы обеспечить целостность данных.

Синтаксис задания ограничения внешнего ключа в InnoDB следующий:

[CONSTRAINT symbol] FOREIGN KEY (index_col_name, ...)
                    REFERENCES table_name (index_col_name, ...)
                    [ON DELETE {CASCADE | SET NULL | NO ACTION
                                | RESTRICT}]
                    [ON UPDATE {CASCADE | SET NULL | NO ACTION
                                | RESTRICT}]

Обе таблицы должны быть InnoDB-типа; обязательно также наличие индекса, в котором внешний ключ и ссылочный ключ должны находиться в ПЕРВЫХ столбцах. Для таблиц InnoDB индексы по внешним ключам или ссылочным ключам не создаются автоматически: их создание требуется задавать явно.

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

Если вы указали действие SET NULL, убедитесь что вы не объявили столбец в дочерней таблице как NOT NULL.

Если оператор MySQL CREATE TABLE выдает ошибку с номером 1005, и в строке сообщения об ошибке присутствует ссылка на ошибку с номером 150, то произошел сбой создания таблицы из-за того, что ограничения внешнего ключа не были сформированы надлежащим образом. Аналогично и для оператора ALTER TABLE: если происходит ошибка при выполнении оператора и в сообщении присутствует ссылка на ошибку с номером 150, то определение внешнего ключа для преобразовываемой таблицы сформировано неправильно.

Начиная с версии 3.23.50 с ограничением внешнего ключа можно также связывать выражения ON DELETE CASCADE или ON DELETE SET NULL. Начиная с версии 4.0.8 вы можете это же использовать с ON UPDATE.

Если указано выражение ON DELETE CASCADE и строка в родительской таблице удалена, то в формате InnoDB все эти строки автоматически удаляются также и из дочерней таблицы, значения внешнего ключа которой равны значениям ссылочного ключа в строке родительской таблицы. Если указано выражение ON DELETE SET NULL, строки дочерней таблицы автоматически обновляются, поэтому столбцам во внешнем ключе также присваивается значение SQL NULL.

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

Начиная с версии 3.23.50 синтаксический анализатор InnoDB обеспечивает возможность использовать обратные кавычки (`), ограничивающие имена таблиц и столбцов в FOREIGN KEY ... REFERENCES ..., однако синтаксический анализатор InnoDB еще ``не знает'' об опции lower_case_table_names, которая может быть задана в файле my.cnf.

Пример:

CREATE TABLE parent(id INT NOT NULL, PRIMARY KEY (id)) TYPE=INNODB;
CREATE TABLE child(id INT, parent_id INT, INDEX par_ind (parent_id),
       FOREIGN KEY (parent_id) REFERENCES parent(id)
       ON DELETE SET NULL
) TYPE=INNODB;

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

ALTER TABLE yourtablename
  ADD [CONSTRAINT symbol] FOREIGN KEY (...) REFERENCES anothertablename(...)

Однако не следует забывать предварительно создавать необходимые индексы. В InnoDB версий < 3.23.50 команды ALTER TABLE или CREATE INDEX не должны использоваться совместно с таблицами, для которых установлены ограничения внешнего ключа или на которые есть ссылки в ограничениях внешних ключей: Команда ALTER TABLE удаляет все ограничения внешних ключей, определенные в таблице. Не следует использовать команду ALTER TABLE для таблиц, на которые есть ссылки; вместо этого необходимо применять команды DROP TABLE и CREATE TABLE, чтобы изменить логическую структуру. При выполнении команды ALTER TABLE MySQL может использовать команду RENAME TABLE, что нарушит ограничения внешнего ключа, относящиеся к таблице. Оператор CREATE INDEX в MySQL обрабатывается таким же образом, как и ALTER TABLE, поэтому приведенные выше ограничения распространяются и на этот оператор.

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

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

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

Начиная с версии 3.23.50 InnoDB возвращает определения внешних ключей таблицы, если вызвать

SHOW CREATE TABLE yourtablename

Помимо этого, mysqldump выводит корректные определения таблиц в файл дампа, ``не забывая'' о внешних ключах.

Список ограничений внешнего ключа таблицы T можно также вывести при помощи команды

SHOW TABLE STATUS FROM yourdatabasename LIKE 'T'

Ограничения внешнего ключа выводятся в комментариях к таблице.

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

В случае восстановления после сбоя InnoDB производит поиск меток контрольных точек, записанных в файлы журналов. Известно, что все изменения базы данных, внесенные перед меткой, уже записаны в образ базы данных на диске. Затем InnoDB производит сканирование файлов журналов начиная от места контрольной точки, и вносит зафиксированные изменения в базу данных.

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

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

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

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

Согласованное чтение является режимом по умолчанию, в котором в InnoDB обрабатываются операторы SELECT при READ COMMITTED или REPEATABLE READ уровнях изоляции. При согласованном чтении не устанавливаются блокировки на таблицы, к которым обращается запрос, и, таким образом, остальные пользователи могут вносить изменения в эти таблицы одновременно с согласованным чтением таблиц.

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

Предположим, что для чтения таблицы PARENT было использовано согласованное чтение, и в таблице была обнаружена родительская строка. Можно ли теперь безопасно добавить дочернюю строку в таблицу CHILD? Нет, потому что в это время другой пользователь мог без вашего ведома удалить родительскую строку из таблицы PARENT.

В данной ситуации необходимо выполнить операцию SELECT в режиме блокировки, LOCK IN SHARE MODE.

SELECT * FROM PARENT WHERE NAME = 'Jones' LOCK IN SHARE MODE;

Выполнение чтения в режиме совместного использования (share mode) означает, что считываются самые новые доступные данные и производится блокировка строк, чтение которых осуществляется. Если последние данные принадлежат еще не зафиксированной транзакции, мы ждем, пока транзакция не будет зафиксирована. Блокировка в режиме совместного использования не позволяет другим пользователям обновить или удалить читаемую строку. После того, как указанный выше запрос вернет родительскую строку 'Jones', мы можем безопасно добавить дочернюю строку в таблицу CHILD и зафиксировать транзакцию. В этом примере показано, как использовать целостность ссылочных данных в своей программе.

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

Для этого случая возможны два способа произвести чтение и увеличить значение счетчика: (1) сначала обновить значение счетчика, увеличив его на 1, и только после этого прочитать его или (2) сначала прочитать счетчик в режиме блокировки FOR UPDATE, а после этого увеличить его значение:

SELECT COUNTER_FIELD FROM CHILD_CODES FOR UPDATE;
UPDATE CHILD_CODES SET COUNTER_FIELD = COUNTER_FIELD + 1;

Оператор SELECT ... FOR UPDATE прочитает последние доступные данные с установкой отдельной блокировки на каждую считываемую строку. Таким образом, блокировка на строки устанавливается точно так же, как и в случае поиска по UPDATE.

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

Блокировка, которая в InnoDB устанавливается на индексные записи, влияет также на интервал перед этой индексной записью. Если у пользователя имеется совместная или эксклюзивная блокировка записи R в индексе, то другой пользователь не может вставить новую индексную запись перед R в порядке следования индексов. Такая блокировка интервалов производится для предотвращения так называемой проблемы с фантомом. Предположим, что необходимо прочитать и заблокировать все дочерние записи с идентификатором, превышающим 100, из таблицы CHILD, и обновить некоторые поля в выбранных строках.

SELECT * FROM CHILD WHERE ID > 100 FOR UPDATE;

Допустим, что создан индекс таблицы CHILD по столбцу ID. Наш запрос произведет сканирование, начиная с первой записи, в которой ID больше 100. Теперь, если установленная на записи индекса блокировка не заблокирует вставки в интервалы, за это время в таблицу может быть вставлена новая дочерняя запись. Если теперь в транзакции запустить

SELECT * FROM CHILD WHERE ID > 100 FOR UPDATE;

еще раз, то в результате запроса будет выдана новая дочерняя запись. Это противоречит принципу изоляции транзакции: транзакция должна запускаться таким образом, чтобы считываемые ею данные не изменялись на протяжении выполнения транзакции. Если мы рассматриваем набор строк как элемент данных, то новая дочерняя ``запись-фантом'' нарушит этот принцип изоляции.

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

Блокировку следующего ключа можно использовать для того, чтобы провести проверку уникальности значений в своей программе. Если данные считываются в режиме совместного доступа и отсутствует дубликат строки, которую необходимо вставить, то можно безопасно вставлять свою строку и быть уверенным, что благодаря блокировке следующего ключа, установленной на предшествующей строке во время чтения, будет предотвращена вставка дублирующейся строки. Таким образом, блокировка следующего ключа позволяет ``заблокировать'' отсутствие чего-либо в таблице.

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

InnoDB не может обнаружить взаимоблокировку, установленную оператором MySQL LOCK TABLES, или блокировку, установленную отличным от InnoDB обработчиком таблиц. Такие ситуации необходимо исправлять при помощи параметра innodb_lock_wait_timeout, который задается в my.cnf.

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

Допустим, вы используете уровень изоляции, установленый по умолчанию - REPEATABLE READ. При выполнении согласованного чтения (т.е. обычного оператора SELECT) InnoDB определяет для транзакции момент времени, по состоянию на который запросу будет предоставляться информация из базы данных. Таким образом, если транзакция удаляет строку и фиксирует это изменение после назначенного момента времени, то вы не увидите, что строка была удалена. Это справедливо также для вставок и обновлений.

Чтобы такой момент времени ``передвинуть вперед'', нужно зафиксировать транзакцию, а затем выполнить новую команду SELECT.

Это называется многовариантным контролем совпадений.

     Пользователь A     Пользователь B

    SET AUTOCOMMIT=0; SET AUTOCOMMIT=0;

время
|     SELECT * FROM t;
|   пустой набор данных
|         INSERT INTO t VALUES (1, 2);
|
v     SELECT * FROM t;
    пустой набор данных
          COMMIT;
    SELECT * FROM t;
    пустой набор данных;

    COMMIT;

    SELECT * FROM t;
    ---------------------
    | 1 | 2 |
    ---------------------

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

Чтобы увидеть ``самое свежее'' состояние базы данных, необходимо использовать чтение с блокировкой:

SELECT * FROM t LOCK IN SHARE MODE;

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

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

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

1. Если top операционной системы Unix или Task Manager Windows показывают процент рабочей нагрузки процессора меньше 70%, это значит, что объем рабочей нагрузки в основном сводится к обращениям к диску. Возможно, слишком часто производится фиксация транзакций, или буферный пул слишком мал. Здесь может помочь увеличение размера буферного пула, но не следует устанавливать его значение большим, чем 80% физической памяти.

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

3. Если вы можете позволить себе потерять последние зафиксированные транзакции, установите параметр innodb_flush_log_at_trx_commit в файле my.cnf в нулевое значение. Так или иначе InnoDB пытается сохранить журнал ежесекундно, и в этом случае сохранение не гарантируется.

4. Увеличьте размеры файлов журналов, доведите их даже до размера буферного пула. Когда InnoDB заполняет файлы журналов, он должен сохранить измененное содержимое буферного пула на диск в виде моментального снимка базы. Маленькие журналы будут вызывать множество ненужных записей на диск. Есть и оборотная сторона медали - если файлы журналов большие, то время восстановления транзакций (в случае сбоя) будет больше.

5. Кроме того, буфер журнала должен быть достаточно большим, например 8 Мб.

6. (Актуально для версии 3.23.39 и выше.) В некоторых версиях операционных систем Linux и Unix запись файлов на диск при помощи команды Unix fdatasync и других подобных методов производится на удивление медленно. Принятый по умолчанию метод InnoDB использует функцию fdatasync. Если скорость записи базы данных вас не устраивает, можно попробовать для параметра innodb_flush_method в файле my.cnf задать значение O_DSYNC, хотя на многих системах O_DSYNC обычно работает медленнее.

7. При импортировании данных в InnoDB убедитесь что в MySQL не установлено значение autocommit=1. Если оно установлено, то каждая вставка требует сохранения журналов на диске. Поместите прямо в начале вашего файла с данными:

SET AUTOCOMMIT=0;

и в конце

COMMIT;

Если используется параметр mysqldump --opt, то вы получите файлы, которые достаточно быстро импортируются в InnoDB, даже если их не окружить вышеуказанными командами SET AUTOCOMMIT=0; ... COMMIT;.

8. Осторожно относитесь к значительным откатам больших вставок InnoDB использует буфер вставок для того, чтобы меньше ``дергать'' диск на вставках, однако для соответствующего отката транзакции такой механизм не предусмотрен.. Ограниченный производительностью диска откат может занять в 30 раз больше времени, чем вставка. Удаление процесса базы данных не поможет, так как откат начнется снова после запуска базы данных. Единственный способ избежать такого отката - это увеличить буферный пул настолько, что откат станет зависеть только от производительности процессора, перестанет ``равняться'' по диску и отработается быстро. Есть еще один способ - это удаление базы данных InnoDB целиком.

9. Следует также осторожно относиться к операциям со значительными объемами данных, зависящим от производительности диска. Чтобы очистить таблицу, используйте команды DROP TABLE или TRUNCATE (начиная с версии MySQL-4.0 и выше), а не DELETE FROM yourtable.

10. Используйте множественные вставки для уменьшения нагрузки на коммуникации между клиентом и сервером, если вам нужно вставить множество записей:

INSERT INTO yourtable VALUES (1, 2), (5, 5);

Эта рекомендация подходит для вставок в таблицы любого типа, а не только InnoDB.

Начиная с версии 3.23.41 в состав InnoDB входит InnoDB Monitor, который выводит информацию по внутреннему состоянию InnoDB. Когда InnoDB Monitor включен, сервер MySQL mysqld выводит стандартный набор данных (обратите внимание: клиент MySQL ничего не выводит) примерно каждые 15 секунд. Эти данные могут пригодиться при настройке производительности. В операционной системе Windows необходимо запустить mysqld-max из командной строки MS-DOS с параметрами --standalone --console, чтобы направить выводимые данные в окно MS-DOS.

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

Выводящаяся информация включает следующие данные:

InnoDB Monitor можно запустить при помощи следующей команды SQL:

CREATE TABLE innodb_monitor(a int) type = innodb;

а остановить его при помощи:

DROP TABLE innodb_monitor;

Вызов команды CREATE TABLE является только способом передачи команды в InnoDB через программу синтаксического анализа SQL. Факт создания таблицы не играет никакой роли для InnoDB Monitor. Если вы останавливаете сервер, когда монитор работает, и хотите запустить монитор заново, следует уничтожить таблицу прежде, чем снова вызвать CREATE TABLE для запуска монитора. Синтаксис может измениться в будущих версиях.

Пример информации, выводимой InnoDB Monitor:

================================
010809 18:45:06 INNODB MONITOR OUTPUT
================================
--------------------------
LOCKS HELD BY TRANSACTIONS
--------------------------
LOCK INFO:
Number of locks in the record hash table 1294
LOCKS FOR TRANSACTION ID 0 579342744
TABLE LOCK table test/mytable trx id 0 582333343 lock_mode IX
RECORD LOCKS space id 0 page no 12758 n bits 104 table test/mytable index
PRIMARY trx id 0 582333343 lock_mode X
Record lock, heap no 2 PHYSICAL RECORD: n_fields 74; 1-byte offs FALSE;
info bits 0
0: len 4; hex 0001a801; asc ;; 1: len 6; hex 000022b5b39f; asc ";;
2: len 7; hex 000002001e03ec; asc ;; 3: len 4; hex 00000001;
...
-----------------------------------------------
CURRENT SEMAPHORES RESERVED AND SEMAPHORE WAITS
-----------------------------------------------
SYNC INFO:
Sorry, cannot give mutex list info in non-debug version!
Sorry, cannot give rw-lock list info in non-debug version!
-----------------------------------------------------
SYNC ARRAY INFO: reservation count 6041054, signal count 2913432
4a239430 waited for by thread 49627477 op. S-LOCK file NOT KNOWN line 0
Mut ex 0 sp 5530989 r 62038708 sys 2155035;
rws 0 8257574 8025336; rwx 0 1121090 1848344
-----------------------------------------------------
CURRENT PENDING FILE I/O'S
--------------------------
Pending normal aio reads:
Reserved slot, messages 40157658 4a4a40b8
Reserved slot, messages 40157658 4a477e28
...
Reserved slot, messages 40157658 4a4424a8
Reserved slot, messages 40157658 4a39ea38
Total of 36 reserved aio slots
Pending aio writes:
Total of 0 reserved aio slots
Pending insert buffer aio reads:
Total of 0 reserved aio slots
Pending log writes or reads:
Reserved slot, messages 40158c98 40157f98
Total of 1 reserved aio slots
Pending synchronous reads or writes:
Total of 0 reserved aio slots
-----------
BUFFER POOL
-----------
LRU list length 8034
Free list length 0
Flush list length 999
Buffer pool size in pages 8192
Pending reads 39
Pending writes: LRU 0, flush list 0, single page 0
Pages read 31383918, created 51310, written 2985115
----------------------------
END OF INNODB MONITOR OUTPUT
============================
010809 18:45:22 InnoDB starts purge
010809 18:45:22 InnoDB purged 0 pages

Некоторые примечания по выводу:

Все индексы в InnoDB представляют собой B-деревья, в которых записи индексов хранятся в страницах ответвления дерева. По умолчанию размер индексной страницы составляет 16 Кб. При вставке новых записей InnoDB старается оставить 1 / 16 страницы свободной - для будущих вставок и обновлений индексных записей.

Если записи индекса вставлены в последовательном порядке (в порядке возрастания или убывания), то получившиеся индексные страницы будут заполнены примерно на 15/16. Для записей, которые вставляются в случайном порядке, эти значения составят от 1/2 до 15/16. Если коэффициент заполнения индексной страницы уменьшится и станет ниже 1/2, InnoDB попытается объединить записи индексного дерева, чтобы освободить страницу.

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

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

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

Буфер вставок периодически объединяется с деревьями вторичных индексов в базе данных. Часто, объединив несколько вставок на одной странице индексного дерева, можно за счет этого сократить количество операций ввода/вывода диска. Использование буфера вставки может ускорить вставку в таблицу в 15 раз.

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

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

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

Когда пользователь после запуска базы данных осуществляет первую вставку в таблицу T, где определен автоинкрементный столбец, и пользователь не предоставляет конкретного значения для этого столбца, InnoDB выполняет SELECT MAX(auto-inc-column) FROM T, затем присваивает это значение, увеличенное на единицу, столбцу, и автоматически увеличивает счетчик таблицы. Эту последовательность действий мы называем инициализацией счетчика автоматического увеличения для таблицы T.

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

Обратите внимание: если пользователь указывает при вставке значение автоинкрементного столбца 0, то InnoDB обрабатывает строку так, как будто значение не было указано.

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

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

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

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

В Windows NT для таблиц InnoDB используется ввод/вывод без буферизации. Это означает, что страницы на диске, которые записывает или считывает InnoDB, не заносятся в файловый кэш операционной системы. При этом экономится некоторое количество памяти.

Начиная с версии 3.23.41 в InnoDB используется новая техника сбрасывания файлов на диск, которая получила название двойной записи. Она обеспечивает большую безопасность при восстановлении после сбоев (таких как, например, зависание операционной системы или отключение питания) и повышение производительности на большинстве версий Unix, так как снижается необходимость в операциях fsync.

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

Начиная с версии 3.23.41 в качестве файла данных можно также использовать раздел реального диска, хотя тестирование этой возможности еще не проводилось. При создании нового файла данных в innodb_data_file_path сразу после размера файла данных необходимо ввести ключевое слово newraw. Раздел диска должен быть больше указанного размера или равен ему. Обратите внимание: 1 Мб в InnoDB -это 1024 x 1024 байт, тогда как в характеристиках диска 1 Мб обычно соответствует 1000 000 байт.

innodb_data_file_path=hdd1:5Gnewraw;hdd2:2Gnewraw

При новом запуске базы данных Вы должны изменить ключевое слово на raw. В противном случае InnoDB перезапишет ваш раздел!

innodb_data_file_path=hdd1:5Graw;hdd2:2Graw

Используя реальный диск, в некоторых версиях Unix можно производить небуферизованные операции ввода/вывода.

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

Табличную область InnoDB составляют файлы данных, определенные в файле конфигурации. Файлы используются последовательно, распределения данных (striping ) по ним не производится. На данный момент вы не можете непосредственно указать, где должны быть размещены таблицы. Можно только воспользоваться знанием того факта, что для вновь созданной табличной области InnoDB будет распределяться место с начала памяти.

Табличная область состоит из страниц базы данных, принятый по умолчанию размер которых составляет 16 Кб. Эти страницы сгруппированы в блоки по 64 последовательных страницы. 'Файлы' внутри табличной области в InnoDB называются сегментами. Название 'сегмент отката' несколько не соответствует действительности, так как фактически в нем содержится много сегментов табличной области.

Для каждого индекса в InnoDB выделяется два сегмента: один - для конечных узлов B-дерева, а другой - для остальных узлов. Идея заключается в том, чтобы получить лучшее координирование конечных узлов, в которых содержатся данные.

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

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

Когда вы запускаете запрос SHOW TABLE STATUS FROM ... LIKE ... для получения информации по доступному свободному пространству табличной области, InnoDB предоставит данные по свободным областям табличной области. InnoDB всегда резервирует области для очистки и других внутренних операций. Зарезервированные области не включаются в объем свободного пространства.

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

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

Скорость сканирования индекса может возрасти, если периодически использовать команду mysqldump для копирования дампа таблицы в текстовый файл, записи диска на диск и повторного считывания таблицы из дампа. Есть еще один способ произвести дефрагментацию - преобразовать таблицу при помощи команды ALTER в тип MyISAM, а затем обратно в тип InnoDB. Обратите внимание на то, что таблица типа MyISAM должна помещаться в один файл в вашей операционной системе.

Если вставки в индекс всегда производятся последовательно, а удаления - только с конца, то алгоритм управления файловым пространством InnoDB гарантирует, что фрагментации индекса не возникнет.