Определить это в статистических терминах довольно сложно, вы можете буквально посчитать и вычислить дополнительные затраты ввода-вывода.
Давайте возьмем таблицу с 1 миллионом строк, и не будем допускать заполнение страниц, сжатие и использовать несколько простых рисунков.
Учитывая таблицу, размер строки которой составляет 100 байтов, которая содержит 10 крошечных. Количество строк на странице (при условии отсутствия заполнения / фрагментации) составляет 80 (8096/100)
При использовании Bigints к размеру строки будет добавлено в общей сложности 70 байтов (10 полей, каждое на 7 байтов больше), что даст размер строки 170 байтов и уменьшит число строк на странице до 47.
Для 1 миллиона строк это приводит к 12500 страницам для крошечных и 21277 страниц для Bigints.
Если взять один диск с последовательным чтением, мы можем ожидать 300 операций ввода-вывода в секунду при последовательном чтении, и каждое чтение составляет 8 КБ (например, страница).
Соответствующее время чтения данного теоретического диска составляет 41,6 секунды и 70,9 секунды - для очень теоретического сценария составленной таблицы / строки.
Это, однако, относится только к сканированию при поиске по индексу, увеличение IO будет относительно небольшим, в зависимости от того, сколько из bigint было в индексе или кластерном ключе. С точки зрения резервного копирования и восстановления, как уже упоминалось, данные расширяются, и потерю времени можно рассчитать как линейную, если не используется сжатие.
С точки зрения кэширования памяти каждый потерянный байт на странице на диске - это потерянный байт в памяти, но он применяется только к страницам в памяти - это будет более сложным, так как потеря памяти будет основана на том, сколько страниц находится в пуле буферов, но для приведенного выше примера это будет в целом 97,6 мегабайт данных против 166 мегабайт данных, и при условии, что вся таблица была отсканирована и, таким образом, в пуле буферов, вы бы тратили 78 мегабайт памяти.