Используйте наиболее эффективные (наименьшие) типы данных. 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 символов.

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

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