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

Question

Я пишу новую программу, для которой потребуется база данных (SQL Server 2008). Все, что я сейчас запускаю для системы, является 64-битным, что подводит меня к этому вопросу. Должен ли я сделать их все INT или BIGINT для всех столбцов Id в разных таблицах? Я сомневаюсь, что система когда-либо превысит диапазон INT, но я полагаю, что это возможно в некоторых более крупных финансовых таблицах. Кажется, что INT является стандартом, хотя ...

Answer 1

ОК, давайте сделаем быстрый математический обзор:

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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