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 TABLEROW_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.