Идентификаторы базы данных SQL Server Int или BigInt

Ответ 1

Хорошо, сделайте краткое изложение математики:

• INT 32-битный и дает вам в основном 4 миллиарда значений - если вы только считаете значения больше нуля, это еще 2 миллиарда. У вас есть много сотрудников? Клиенты? Продукты в наличии? Заказы на всю жизнь вашей компании? ДЕЙСТВИТЕЛЬНО?

• BIGINT идет намного дальше. Вам это действительно нужно? действительно?? Если вы астроном или физика частиц - может быть. Средняя личность бизнес-пользователя? Я очень сомневаюсь в этом

Представьте, что у вас есть таблица с - скажем - 10 миллионов строк (заказы для вашей компании). Скажем, у вас есть таблица Orders, и что OrderID, который вы создали BIGINT, ссылается на 5 других таблиц и используется в 5 некластеризованных индексах в вашей таблице Orders - не переусердствуйте, я думаю, правильно?

10 миллионов строк, по 5 таблиц плюс 5 некластеризованных индексов, 100 миллионов экземпляров, в которых вы используете 8 байтов вместо 4 байтов - 400 миллионов байт = 400 МБ. Общий объем отходов... вам понадобится больше данных и индексных страниц, ваш SQL Server должен будет читать больше страниц с диска и кэшировать больше страниц... что не выгодно для вашей производительности - просто и просто.

ПЛЮС: о том, что большинство программистов не думает: да, дисковое пространство это грязное дешево. Но это потраченное впустую пространство также актуально в вашей RAM-памяти SQL Server и кеше базы данных - и это пространство не дешево!

Итак, чтобы сделать очень длинную запись короткой: используйте наименьший тип INT, который действительно соответствует вашим потребностям; если у вас есть 10-20 различных значений для обработки - используйте TINYINT. Если вам нужна таблица заказов, я считаю, что INT должен быть PLENTY ENOUGH. BIGINT - это всего лишь пустая трата пространства.

Плюс: если какая-либо из ваших таблиц действительно приблизится к достижению 2 или 4 миллиардов строк, у вас все равно будет достаточно времени, чтобы обновить таблицу до BIGINT ID, если это действительно необходимо.......

Ответ 2

Вы должны использовать наименьший тип данных, который имеет смысл для рассматриваемой таблицы. Это включает использование smallint или даже tinyint, если количества строк достаточно.

Вы сэкономите место на данных и индексах и получите лучшую производительность индекса. Использование bigint, когда все, что вам нужно, это smallint, похоже на использование varchar(4000), когда все, что вам нужно, это varchar(50).

Даже если размер исходного словаря машины составляет 64 бита, это означает только то, что 64-битные операции ЦП не будут медленнее 32-разрядных операций. Большую часть времени они также не будут быстрее, они будут одинаковыми. Но в большинстве случаев большинство баз данных не будут связаны с ЦП, они будут связаны с I/O и в меньшей степени связаны с памятью, поэтому размер данных на 50% -90% - это очень хорошая вещь, когда вам нужно выполнить индекс сканирует более 200 миллионов строк.

Ответ 3

Вот статья с некоторыми реальными ответами на производительность... Я предпочитаю отвечать на вопросы с жесткими цифрами, если это возможно... Если вы нажмете следующую ссылку, по крайней мере, до миллиона записей, вы найдете незначительную разницу на диске использование....

http://www.sqlservercentral.com/articles/Performance+Tuning/2753/

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

Рассмотрим репозиторий файлов на сайте сообщества или идентификатор комментариев пользователя на многопользовательском сайте сообщества.

Я понимаю, что большинство разработчиков строят системы, которые никогда не коснутся миллионов записей, но важно отметить, что есть причины, по которым требуется bigint, и я все еще не убежден, что при разработке схемы, которую вы не знаю потенциального роста для этого, вам не следует пытаться предвидеть будущее и подумать об использовании bigint, если вы чувствуете, что потенциал превышает максимальное значение int при увеличении значения id.

Ответ 4

Выравнивание 32-битных чисел с архитектурой x86 или 64-разрядной архитектурой x64 называется выравнивание структуры данных

Это не имеет никакого значения для данных в базе данных, потому что здесь есть пространство на диске, кеш данных и архитектура таблицы/индекса, которые влияют на производительность (как упоминалось в других ответах).

Помните, что это не центральный процессор, получающий доступ к данным как таковым. Это код двигателя БД (который может быть выровнен, но кто заботится?), Который работает на процессоре и управляет вашими данными. Когда/если ваши данные проходят через CPU, это, конечно, не будет в одинаковых структурах на диске.

Ответ 5

Другие люди уже дали убедительные ответы для 32-битных идентификаторов.

Для некоторых приложений 64-битные идентификаторы имеют больше смысла.

Если вы хотите гарантировать уникальность идентификаторов в кластере баз данных - 63-битные идентификаторы могут быть очень удобными. С 32 битами очень сложно распространять генерацию идентификаторов на серверах в кластере; или через центры обработки данных. Хотя с 64 битами у вас достаточно места для игры, вы можете легко генерировать идентификаторы на серверах без блокировки и по-прежнему гарантировать уникальность.

Например, см. Twitter Snowflake и сообщение в блоге Instagram Engineering в разделе "Облицовка и идентификаторы в Instagram" , Оба являются вескими причинами, по которым 63 или 64 бита имеют больше смысла для их идентификаторов, чем 32-разрядные счетчики.

Ответ 6

Вы должны судить каждую таблицу отдельно о том, какой тип данных будет соответствовать потребностям каждого из них. Используйте INTEGER для удовлетворения потребностей конкретной таблицы. Если SMALLINT будет достаточным, используйте это. Используйте тип данных, который будет длиться, без чрезмерного.

Ответ 7

Первый ответ - наивный ответ для тех, кто не работает с базами данных TB или таблицами с постоянными и большими томами. В любой базе данных подходящего размера вы столкнетесь с проблемами с INT на определенном этапе своей жизни. Используйте BIGINT, если вам нужно, поскольку это сэкономит много хлопот дальше по линии. Я видел, как компании попали в проблему INT после всего лишь одного года данных, и когда пересыщение не было вариантом, это вызвало массовый простоя. Также в системах с длительным сроком службы (10 лет +), где система не должна была использоваться, она попала даже в базы данных умеренного размера, которые очищают старые данные. Гораздо лучше использовать GUID в большинстве случаев, когда ожидаются большие объемы данных, но запрет на использование BIGINT, если требуется.