2009-10-07 1 views
2

С MySQL я часто пропускаю некоторые параметры, такие как «подписанные/неподписанные» и «разрешать null», но мне интересно, могут ли эти данные замедлить работу веб-приложения.Улучшения производительности для таблиц

Есть ли заметные различия в производительности в этих ситуациях?

  1. используя низкий/высокий диапазон Integer первичного ключа
    • 5000 строки с идентификаторами от 1 до 5000
    • 5000 строк с идентификаторами от 20001 до 25000
  2. Целого ПК приращения равномерно vs неравномерно.
    • 5000 строк с идентификаторами от 1 до 5000
    • 5000 строк с идентификаторами, рассеянных от 1 до 30000
  3. Установка Integer PK, как беззнаковое против подписал
    • пример: где коэффициент усиления в диапазоне unsigned на самом деле не требуется
  4. Установка значения по умолчанию для поля (любого типа) по умолчанию по умолчанию
    • пример: обновление строки и все данные поля определяется
  5. Разрешить Null против отрицать Null
    • пример: обновление строки и все данные поля дается

Я использую MySQL, но это более общий вопрос.

ответ

0

используя низкий/высокий диапазон Integer первичного ключа * 5000 строк с идентификаторами от 1 до 5000 * 5000 строк с идентификаторами от 20001 до 25000

Не имеет никакого значения.

Целочисленный PK с равномерным увеличением равномерно. * 5000 строк с идентификаторами от 1 до 5000 * 5000 строк с идентификаторами рассеянных от 1 до 30000

Если распределение равномерное, это делает не разница.

Равномерное распределение может помочь в создании более эффективного случайного запроса выборки, как описано в этой статье в своем блоге:

Это распределение, которое имеет значение, а не оценки: в порядке, 1, 2, 3, 31 нет.

Установка Integer PK, как беззнаковое против подписал * Пример: где выигрыш в диапазоне от неподписанный на самом деле не требуется

Если вы объявляете PRIMARY KEY в UNSIGNED, MySQL может оптимизировать из предикаты как id >= -1

Установка значения по умолчанию для поля (любого типа) по сравнению не по умолчанию * например: обновление строки и всех полевых данных

Без разницы.

Разрешить Null против отрицать Null * Пример: обновление строки и все данные поля определяется

Обнуляемые столбцы один байт больше: ключевой индекс для INT NOT NULL длиной байт, что для INT NULL составляет байт.

1

Из моего понимания B-деревьев (так обычно реализуются реляционные базы данных, верно?), Эти вещи не должны иметь никакого значения. Все, что вам нужно, это быстрая функция сравнения на вашем ключе, и обычно это не имеет значения, какой диапазон целых чисел вы используете (если только вы не выберете размер машинного слова).

Конечно, для ключей единое значение по умолчанию или разрешение null не имеет большого смысла. Во всех неключевых полях предоставление нулевых значений или предоставление значений по умолчанию не должно оказывать существенного влияния.

1

5000 строк почти ничего для базы данных. Обычно они используют большие B-деревья для индексов, поэтому им все равно о распределении первичных ключей.

Как правило, использование других опций должно основываться на том, что вам нужно от приложения базы данных. Они не могут существенно повлиять на производительность. Таким образом, используйте значение по умолчанию, если вы хотите значение по умолчанию, используйте параметр NOT NULL, если вы не хотите, чтобы столбец был NULL.

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