Какой размер int вы бы использовали для полей внешнего ключа?

Question

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

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

Answer 1

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

Answer 2

На 32-битном сервере меньшие целые числа не помогут вам сэкономить на производительности процессора, тем более на 64-битном сервере. Возможно, вы получите экономию диска и, следовательно, некоторое улучшение диска, но в целом общее улучшение может быть незначительным.

Answer 3

Ваш коллега не прав. Если вы используете четырехбайтовые целые числа для внешних ключей, то первичные ключи в таблице фактов также должны быть 4-байтовыми целыми числами. И затем вы делаете свою таблицу фактов шире, чем нужно, сокращая количество записей, которые могут поместиться на одной странице индекса. В той степени, в которой это меняет ширину индекса первичного ключа, это отрицательно скажется на производительности индекса. Если ваш первичный ключ мог быть двумя tinyInts и 3 smallints, и вы изменили его на пять 4-байтовых, вы изменили ширину индекса с 8 байтов в ширину до 20 байтов в ширину. Ваш индекс будет иметь вдвое меньше записей на страницу ввода / вывода, и для его прохождения потребуется вдвое больше логических и / или физических чтений.

ПРИМЕЧАНИЕ. Как показывает ответ Джима Маклеода ниже, SQL Server 2008 (Enterprise или Developer edition) включает сжатие на уровне строк, что означает, что вы можете объявить значение как 4-байтовый INT, но оно сохранит значение в тип наиболее подходящего размера для каждой строки.

Answer 4

4-байтовые целые числа для первичных ключей подходят для большинства решений.

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

Иногда только это может придать вашему решению дополнительную производительность, поскольку не требуется выполнять поиск в базе данных для получения нового идентификатора записи. (т.е. создайте его в слое DAL и сохраните его сразу, вместо того, чтобы использовать что-то вроде scope_identity () или @@ Identity)

Надеюсь, это поможет.

Answer 5

Как всегда с вопросами производительности, это зависит. Если ваши строки фактов крошечные, скажем, 20 байтов каждая, то экономия двух байтов на строку сэкономит 400 байтов и позволит вам разместить дополнительные 20 строк на каждой странице. Если ваши строки фактов больше, скажем, 500 байтов, то вы сможете сохранить только 32 байта, что не имеет значения.

Преимущество использования INT над SMALLINT состоит в том, что вам не нужно беспокоиться о том, что произойдет, если вы неожиданно получите больше строк, чем ожидали.

SQL Server 2008 включает сжатие на уровне строк, что означает, что вы можете объявить значение как 4-байтовый INT, но оно будет хранить значение в наиболее подходящем размере для каждой строки.