Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL] TABLEtbl_name[,tbl_name] ...
Реорганизовывает физическое хранение табличных данных, и связанный индексируют данные, чтобы уменьшить пространство памяти и улучшить эффективность ввода-вывода, получая доступ к таблице. Точные изменения, произведенные в каждой таблице, зависят от механизма хранения, используемого той таблицей.
Использовать OPTIMIZE TABLE в этих случаях, в зависимости от типа таблицы:
После выполнения существенной вставки, обновления, или удаляют операции на InnoDB таблица, у которой есть ее собственный.ibd
файл, потому что она создавалась с innodb_file_per_table опция включается. Таблица и индексирует,
реорганизовываются, и дисковое пространство может быть исправлено для использования операционной
системой.
После выполнения существенной вставки, обновления, или удаляют операции на
столбцах, которые являются частью a FULLTEXT индексируйте в InnoDB таблица. Установите параметр конфигурации innodb_optimize_fulltext_only=1 сначала. Чтобы сохранить период
ведения индексов к соответствующему времени, установите innodb_ft_num_word_optimize опция, чтобы определить, сколько слова,
чтобы обновить в поиске индексируют, и выполняют последовательность OPTIMIZE
TABLE операторы до поиска индексируют, полностью обновляется.
После удаления значительной части a MyISAM или ARCHIVE таблица, или производящий много изменений в a MyISAM
или ARCHIVE таблица со строками переменной длины (таблицы, которые имеют VARCHAR, VARBINARY, BLOB, или TEXT столбцы). Удаленные строки сохраняются в связанном списке и
последующие INSERT повторное использование операций старые позиции строки. Можно
использовать OPTIMIZE TABLE
исправить неиспользуемое место и дефрагментировать файл данных. После обширных изменений к таблице этот
оператор может также улучшить производительность операторов, которые используют таблицу, иногда
значительно.
Этот оператор требует SELECT и
INSERT полномочия для таблицы.
OPTIMIZE TABLE также поддерживается для разделенных таблиц. Для получения
информации об использовании этого оператора с разделенными таблицами и табличными разделами, см. Раздел
17.3.4, "Обслуживание Разделов".
В MySQL 5.7.1, gtid_next должен быть установлен в AUTOMATIC прежде,
чем сделать это заявление. Это ограничение не применяется в MySQL 5.7.2 или позже. (Ошибка #16062608, Ошибка
#16715809, Ошибка #69045)
OPTIMIZE TABLE работы для InnoDB, MyISAM, и ARCHIVE
таблицы.
По умолчанию, OPTIMIZE TABLE не работает на таблицы, составленные, используя любой другой механизм
хранения, и возвращает результат, указывающий на эту нехватку поддержки. Можно сделать OPTIMIZE TABLE работа для других механизмов хранения, запускаясь mysqld
с --skip-new опция. В этом случае, OPTIMIZE TABLE был только отображен на ALTER TABLE.
Для InnoDB таблицы, OPTIMIZE TABLE отображается на ALTER TABLE, который восстанавливает таблицу, чтобы обновить, индексируют
статистику и свободное неиспользуемое место в кластерном индексе. Это выводится на экран в выводе OPTIMIZE TABLE когда Вы работаете на этом InnoDB
таблица, как показано здесь:
mysql> OPTIMIZE TABLE foo;+----------+----------+----------+-------------------------------------------------------------------+| Table | Op | Msg_type | Msg_text |+----------+----------+----------+-------------------------------------------------------------------+| test.foo | optimize | note | Table does not support optimize, doing recreate + analyze instead || test.foo | optimize | status | OK |+----------+----------+----------+-------------------------------------------------------------------+
Эта работа не использует быстрое создание индекса. Вторичный индексирует, не создаются как эффективно, потому что ключи вставляются в порядок, они появились в первичном ключе. См. Раздел 5.5.9, "Ограничения Онлайнового DDL".
InnoDB данные хранилищ, используя метод выделения страницы и не страдают от
фрагментации таким же образом что механизмы хранения наследства (такой как MyISAM)
будет. Когда рассмотрение, работать ли, оптимизирует, рассматривает рабочую нагрузку транзакций, которые
обработает Ваш сервер:
Некоторый уровень фрагментации ожидается. InnoDB
только страницы заливок полные 93 %,
чтобы оставить комнату для обновлений, не имея необходимость разделять страницы.
Удалите операции, мог бы оставить разрывы, которые оставляют страницы менее заполненными чем требуемый, который мог сделать стоящим оптимизировать таблицу.
Обновления к строкам обычно переписывают данные в пределах той же самой страницы, в
зависимости от типа данных и формата строки, когда достаточное пространство доступно. См. Раздел 5.4.6.5, "Как Работы Сжатия
для Таблиц InnoDB" и Раздела 5.4.8.1,
"Краткий обзор InnoDB Хранение строки".
Рабочие нагрузки высокого параллелизма могли бы оставить разрывы внутри,
индексирует в течение долгого времени, как InnoDB сохраняет многократные
версии тех же самых данных, должных через его механизм MVCC. См. Раздел
14.2.3.11,"InnoDB Мультиуправление версиями".
Для MyISAM таблицы, OPTIMIZE TABLE работы следующим образом:
Если таблица удалила или разделила строки, восстановите таблицу.
Если индексные страницы не сортируются, сортируют их.
Если статистические данные таблицы не современны (и восстановление не могло бы быть выполнено, сортируя индексирование), обновите их.
OPTIMIZE TABLE возвращает набор результатов со следующими столбцами.
| Столбец | Значение |
|---|---|
Table |
Имя таблицы |
Op |
Всегда optimize |
Msg_type |
status, error, info, note, илиwarning |
Msg_text |
Информационное сообщение |
Отметьте, что MySQL блокирует
таблицу в течение времени OPTIMIZE
TABLE работает.
По умолчанию, записи сервера OPTIMIZE
TABLE операторы к двоичному журналу так, чтобы они тиражировались к ведомым устройствам репликации.
Чтобы подавить журналирование, определите дополнительное NO_WRITE_TO_BINLOG
ключевое слово или его псевдоним LOCAL.
OPTIMIZE TABLE не сортирует R-древовидные-индексы, такой, поскольку
пространственный индексирует на POINT столбцы. (Ошибка #23578)
OPTIMIZE TABLE таблица ловит и бросает любые ошибки, которые происходят, копируя
табличную статистику от старого файла до недавно создаваемого файла. Например. если идентификатор пользователя
владельца .frm, .MYD, или .MYI
файл отличается от идентификатора пользователя процесса mysqld, OPTIMIZE TABLE генерирует, "не может изменить владение файла"
ошибка, если mysqld не запускается root
пользователь.