Spec-Zone.ru › MySQL 9.2

10.5.1 Оптимизация структуры хранения данных для таблиц InnoDB

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

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

  • В InnoDB наличие длинного PRIMARY KEY (либо один столбец с длинным значением, либо несколько столбцов, образующих длинное составное значение) приводит к большому расходу места на диске. Значение первичного ключа для строки дублируется во всех записях вторичного индекса, которые указывают на ту же строку. (См. Раздел 17.6.2.1, «Кластеризованные и вторичные индексы».) Создайте столбец AUTO_INCREMENT в качестве первичного ключа, если ваш первичный ключ длинный, или индексируйте префикс длинного столбца VARCHAR вместо всего столбца.

  • Используйте тип данных VARCHAR вместо CHAR для хранения строк переменной длины или для столбцов со многими NULL значениями. Столбец CHAR(N) всегда занимает N символов для хранения данных, даже если строка короче или ее значение NULL. Более мелкие таблицы лучше подходят для буферного пула и уменьшают ввод-вывод на диск.

    При использовании формата строк COMPACT (по умолчанию InnoDB формат) и наборов символов переменной длины, таких как utf8mb4 или sjis, столбцы CHAR(N) занимают переменное количество места, но по-прежнему не менее N байт.

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

© 2025 Oracle
Licensed under the GPLv2 License.
https://docs.oracle.com/cd/E17952_01/mysql-8.4-en/optimizing-innodb-storage-layout.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API