Соответствующее использование mysql Оптимизирует Таблицу

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

Я столкнулся с этой статьей, в которой в основном говорится что таблица Optimize:

  1. не собираясь показывать много улучшения в случае, если Ваши запросы не используют PK.
  2. другие индексы на таблице создаются в псевдослучайном порядке и скорее всего не извлекли бы выгоду из таблицы Optimize.
  3. мог на самом деле сделать Обновления медленнее вследствие того, что теперь каждое изменение имеет более высокую вероятность приведения к расщеплению страницы.

Мои вопросы:

  1. 3 точки выше всегда верны? Частично? Нисколько?
  2. Когда это - хороший выстрел, чтобы попытаться Оптимизировать таблицу?
  3. В котором случаи, Оптимизируя таблицу не принесли бы пользу или даже сделали бы некоторое использование таблицы хуже?
  4. Существует ли способ Оптимизировать индексы таблицы кроме ее PK?
8
22.02.2020, 14:12
1 ответ

Baron Schwartz, автор того сообщения, является одним из соавторов MySQL High Performance, 3-го Выпуска, одной из лучших книг там относительно производительности MySQL. В то время как аргументом полномочий является не всегда хороший, я хотел бы отметить, что, вероятно, он знает то, что он говорит.

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

Фрагментация и расщепление страницы являются щекотливой темой, относительно каких людей как Jeremy Cole http://blog.jcole.us/2013/04/09/innodb-bugs-found-during-research-on-innodb-data-storage/ и инженеры Facebook упомянули много (особенно, к сжатию): https://www.facebook.com/note.php? note_id=10150348315455933 и его последствия на производительности.

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

Существуют некоторые хорошие методы, которые я могу рекомендовать Вам (который является, вероятно, что Вы хотите):

  • Дефрагментация, только если Вы сделали пакет, УДАЛЯЕТ большого количества записей (и Вы не намереваетесь вставить их назад). В других случаях это не может быть необходимо. Если Вы хотите знать, существует ли огромная разница между логическими данными и размером файла, сравните .idb файл с данными + индексный размер от выставочного состояния таблицы.
  • Вставка ускорения путем вставки всегда в порядок PRIMARY KEY, таким образом, Вы не вызываете ненужные расщепления страницы.
  • Используйте разделение для изоляции изменений, которые могут изменить внутреннюю структуру таблицы.
  • Нет никакого способа "оптимизировать вторичные индексы", но я никогда не считал бы такую вещь необходимой. Буфер изменения удостоверяется, что это изменяется/восстанавливает равновесие на индексы, сделаны асинхронно без огромных проблем производительности. B-ДЕРЕВО должно всегда балансироваться, так предполагая, что Ваш буфер изменения не полон, и поток чистки удаляет старые записи строки быстро, Ваша производительность должна быть в порядке. Одним путем я могу думать "об оптимизации вторичных индексов", поскольку Вы назвали ее, ОТБРАСЫВАЕТЕ индекс и воссоздаете ее (предположение, что Вы используете Плагин InnoDB или MySQL 5.5 +), но я не вижу абсолютно никаких оснований, чтобы сделать это.

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

7
22.02.2020, 22:31
  • 1
    большое спасибо для Вашего подробного ответа, это действительно разрешило вещи для меня. –  Daniel A. 22.09.2014, 10:59

Теги

Похожие вопросы