Используйте наиболее эффективные (наименьшие) типы данных. 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 × максимальную длину байта набора символов. Многие языки могут быть записаны в основном с использованием однобайтовых utf8mb3 или utf8mb4 символов, поэтому фиксированная длина хранения часто приводит к потере места. С компактным семейством форматов строк, InnoDB выделяет переменное количество хранилища в диапазоне от N до N × максимальной длины байта набора символов для этих столбцов, удаляя хвостовые пробелы. Минимальная длина хранилища составляет N байт, чтобы облегчить обновления на месте в типичных случаях. Для получения дополнительной информации, см. раздел 17.10, «Форматы строк InnoDB».

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

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

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

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

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

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

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

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

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

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