Spec-Zone.ru › MySQL 5.7

8.4.1 Оптимизация размера данных

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

MySQL поддерживает множество различных движков хранения (типов таблиц) и форматов строк. Для каждой таблицы можно выбрать метод хранения и индексирования. Выбор правильного формата таблицы для вашего приложения может обеспечить значительный прирост производительности. См. главу 14 «Движок хранения InnoDB» и главу 15 «Альтернативные движки хранения».

Можно повысить производительность таблицы и минимизировать занимаемое пространство, используя перечисленные ниже методы:

  • Столбцы таблицы

  • Формат строки

  • Индексы

  • Соединения

  • Нормализация

Столбцы таблицы

  • Используйте наиболее эффективные (наименьшие) типы данных. MySQL имеет множество специализированных типов, которые экономят место на диске и в памяти. Например, используйте более компактные целочисленные типы, если это возможно, чтобы уменьшить размер таблиц. MEDIUMINT зачастую является лучшим выбором, чем INT, так как столбец MEDIUMINT использует на 25% меньше места.

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

Формат строки

  • Таблицы InnoDB создаются по умолчанию с использованием формата строк DYNAMIC. Чтобы использовать формат строк, отличный от DYNAMIC, настройте innodb_default_row_format или явно укажите параметр ROW_FORMAT в операторе CREATE TABLE или ALTER TABLE.

    Семейство компактных форматов строк, включающее COMPACT, DYNAMIC и COMPRESSED, уменьшает занимаемое место строк за счёт увеличения использования ЦП для некоторых операций. Если ваша рабочая нагрузка типична и ограничена скоростью попадания в кэш и скоростью диска, она, скорее всего, будет быстрее. Если это редкий случай, ограниченный скоростью ЦП, она может быть медленнее.

    Семейство компактных форматов строк также оптимизирует хранение столбцов CHAR при использовании наборов символов переменной длины, таких как utf8mb3 или utf8mb4. В формате ROW_FORMAT=REDUNDANT, CHAR(N) занимает N × максимальной длины байт набора символов. Многие языки могут быть написаны в основном с использованием однобайтовых utf8 символов, поэтому фиксированная длина хранения часто приводит к потере места. В семействе компактных форматов строк, InnoDB выделяет переменное количество памяти в диапазоне от N до N × максимальной длины байт набора символов для этих столбцов, удаляя хвостовые пробелы. Минимальная длина хранения составляет N байтов для облегчения обновлений «на месте» в типичных случаях. Для получения дополнительной информации см. Раздел 14.11 «Форматы строк InnoDB».

  • Чтобы ещё более уменьшить занимаемое место, сохраняя данные таблицы в сжатом виде, укажите ROW_FORMAT=COMPRESSED при создании таблиц InnoDB или выполните команду myisampack для существующей таблицы MyISAM. (Сжатые таблицы InnoDB можно читать и записывать, а сжатые таблицы MyISAM — только для чтения.)

  • Для таблиц MyISAM, если у вас нет столбцов переменной длины (VARCHAR, TEXT или BLOB), используется формат строк фиксированной длины. Это быстрее, но может привести к некоторой потере места. См. Раздел 15.2.3 «Форматы хранения таблиц MyISAM». Вы можете указать, что вы хотите иметь строки фиксированной длины даже если у вас есть столбцы VARCHAR с помощью опции CREATE TABLE ROW_FORMAT=FIXED.

Индексы

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

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

  • Если существует высокая вероятность того, что в длинном строковом столбце есть уникальный префикс в первых нескольких символах, лучше проиндексировать только этот префикс, используя поддержку MySQL для создания индекса на левой части столбца (см. Раздел 13.1.14 «Оператор CREATE INDEX»). Более короткие индексы быстрее не только потому, что занимают меньше места на диске, но и потому, что обеспечивают больше попаданий в кэш индекса, а следовательно, меньше обращений к диску. См. Раздел 5.1.1 «Настройка сервера».

Соединения

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

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

  • Используйте простые имена столбцов, чтобы вы могли использовать одно и то же имя в разных таблицах и упростить запросы соединения. Например, в таблице с именем customer используйте имя столбца name вместо customer_name. Чтобы сделать ваши имена совместимыми с другими серверами SQL, рекомендуется сохранять их длиной менее 18 символов.

Нормализация

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

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

© 2025 Oracle
Licensed under the GPLv2 License.
https://docs.oracle.com/cd/E17952_01/mysql-5.7-en/data-size.html

Spec-Zone.ru

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