Spec-Zone .ru
спецификации, руководства, описания, API
|
Разработайте свои таблицы, чтобы минимизировать их пространство на диске. Это может привести к огромным улучшениям, уменьшая объем данных, записанный и читать из диска. Меньшие таблицы обычно требуют менее оперативной памяти, в то время как их содержание активно обрабатывается во время выполнения запроса. Любое сокращение пространства для табличных данных также приводит к меньшему, индексирует, который может быть обработан быстрее.
MySQL поддерживает много различных механизмов хранения (табличные типы) и форматы строки. Для каждой таблицы можно решить который хранение и метод индексации, чтобы использовать. Выбор надлежащего формата таблицы для Вашего приложения может дать Вам большое увеличение производительности. См. Главу 14, Механизмы Хранения.
Можно получить лучшую производительность для таблицы и минимизировать пространство памяти при использовании методов, перечисленных здесь:
Используйте самые эффективные (самые маленькие) возможные типы данных. У MySQL есть
много специализированных типов, которые сохраняют дисковое пространство и память. Например, используйте
меньшие целочисленные типы если возможный, чтобы получить меньшие таблицы. MEDIUMINT
часто лучший выбор чем INT
потому что a MEDIUMINT
столбец использует на 25 % меньше пространства.
Объявите, что столбцы NOT NULL
если возможный. Это
делает операции SQL быстрее, включая лучшему использованию индексирует и издержки устранения для того,
чтобы протестировать, является ли каждое значение NULL
. Вы также сохраняете
некоторое пространство памяти, один бит для каждого столбца. Если Вы действительно нуждаетесь NULL
значения в Ваших таблицах, используйте их. Только избегите настройки
по умолчанию, которая позволяет NULL
значения в каждом столбце.
InnoDB
таблицы используют компактный формат хранения. В
версиях MySQL ранее чем 5.0.3, InnoDB
строки содержат некоторую избыточную
информацию, такую как число столбцов и длина каждого столбца, даже для столбцов фиксированного размера.
По умолчанию таблицы составляются в компактном формате (ROW_FORMAT=COMPACT
).
Если Вы хотите понизить к более старым версиям MySQL, можно запросить старый формат с ROW_FORMAT=REDUNDANT
.
Присутствие компактной строки форматирует пространство памяти строки уменьшений приблизительно на 20 % за счет увеличивающегося использования ЦП для некоторых операций. Если Ваша рабочая нагрузка будет типичной, которая ограничивается уровнями удачного обращения в кэш и дисковой скоростью, то это, вероятно, будет быстрее. Если это - редкий случай, который ограничивается скоростью ЦП, это могло бы быть медленнее.
Компактное InnoDB
отформатируйте также изменяется как CHAR
столбцы, содержащие данные UTF-8, сохранены. С ROW_FORMAT=REDUNDANT
, UTF-8 CHAR(
занимает 3 × N
)N
байты, учитывая, что максимальная длина UTF-8
закодированный символ составляет три байта. Много языков могут быть записаны, прежде всего используя
однобайтовые символы UTF-8, таким образом, фиксированная длина хранения часто тратит впустую
пространство. С ROW_FORMAT=COMPACT
формат, InnoDB
выделяет переменное количество хранения в диапазоне от N
к 3 × N
байты для этих столбцов, разделяя конечные пробелы в случае необходимости. Минимальная длина
хранения сохраняется как N
байты, чтобы облегчить
оперативные обновления в типичных случаях.
Чтобы минимизировать пространство еще далее, храня табличные данные в сжатой форме,
определить ROW_FORMAT=COMPRESSED
создавая InnoDB
таблицы, или выполненный myisampack команда на существующем MyISAM
таблица. (InnoDB
таблицы сжатые
таблицы читаемы и перезаписываемы, в то время как MyISAM
сжатые таблицы
только для чтения.)
Для MyISAM
таблицы, если у Вас нет никаких столбцов
переменной длины (VARCHAR
,
TEXT
, или BLOB
столбцы), формат строки фиксированного размера используется. Это
быстрее, но может потратить впустую некоторое пространство. См. Раздел
14.3.3,"MyISAM
Табличные Форматы Хранения". Можно
подсказать, что Вы хотите иметь строки фиксированной длины, даже если Вы имеете VARCHAR
столбцы с CREATE TABLE
опция ROW_FORMAT=FIXED
.
Основное устройство индексирует таблицы, должно быть настолько коротким насколько
возможно. Это делает идентификацию каждой строки легкой и эффективной. Для InnoDB
таблицы, столбцы первичного ключа дублируются в каждом вторичном
элементе индекса, таким образом, короткий первичный ключ оставляет значительное свободное место, если Вы
имеете, многие вторичные индексируют.
Создайте только индексирование этого, Вы должны улучшить производительность запроса. Индексирует хороши для извлечения, но замедляются, вставляют и обновляют операции. Если Вы получаете доступ к таблице главным образом, ища на комбинации столбцов, создаете единственный сводный индекс на них, а не отдельное индексируют для каждого столбца. Первая часть индексирования должна быть наиболее используемым столбцом. Если Вы всегда используете много столбцов, выбирая из таблицы, первый столбец в индексировании должен быть тем с большинством копий, чтобы получить лучшее сжатие индексирования.
Если вероятно, что у длинного строкового столбца есть уникальный префикс на первом
числе символов, лучше индексировать только этот префикс, используя поддержку MySQL создания
индексирования на крайней левой части столбца (см. Раздел
13.1.11,"CREATE INDEX
Синтаксис"). Короче индексирует,
быстрее, не только потому, что они требуют меньшего дискового пространства, но потому что они также дают
Вам больше хитов в индексировать кэше, и таким образом меньше поиска на диске. См. Раздел
8.11.2, "Настраивая Параметры Сервера".
При некоторых обстоятельствах это может быть выгодно, чтобы разделить на два таблица, которая сканируется очень часто. Это - особенно истина, если это - таблица динамического формата, и возможно использовать меньшую статическую таблицу формата, которая может использоваться, чтобы найти соответствующие строки, сканируя таблицу.
Объявите столбцы с идентичной информацией в различных таблицах с идентичными типами данных, чтобы ускорить соединения, основанные на соответствующих столбцах.
Сохраните имена столбцов простыми, так, чтобы можно было использовать то же самое
имя через различные таблицы и упростить запросы соединения. Например, в таблице называется customer
, используйте имя столбца name
вместо customer_name
. Чтобы сделать Ваши имена переносимыми на другие
SQL-серверы, рассмотрите хранение их короче чем 18 символов.
Обычно, попытайтесь сохранить все данные безызбыточными (наблюдающий, что упоминается в теории баз данных как третья нормальная форма). Вместо того, чтобы повторить длинные значения, такие как имена и адреса, присвойте их уникальные ID, повторите эти ID как необходимый через многократные меньшие таблицы, и присоединитесь к таблицам в запросах, ссылаясь на ID в пункте соединения.
Если скорость более важна чем дисковое пространство и затраты на обслуживание хранения многократных копий данных, например в сценарии анализа бизнес-данных, откуда Вы анализируете все данные больших таблиц, можно ослабить правила нормализации, копируя информацию или создавая сводные таблицы, чтобы получить больше скорости.