Улучшения производительности для таблиц

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

Не имеет значения.

Целочисленные значения PK увеличиваются равномерно по сравнению с неравномерно. * 5000 строк с идентификаторами от 1 до 5000 * 5000 строк с идентификаторами, разбросанными от 1 до 30000

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

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

• PostgreSQL 8.4: выборка случайных строк

Важно распределение, а не границы: 1, 11, 21, 31 в порядке, 1, 2, 3, 31 - нет.

Установка Integer PK как неподписанного или подписанного * пример: где усиление в диапазоне без знака фактически не требуется

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

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

Без разницы.

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

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