У меня есть таблица с 490 M строк и 55 ГБ табличного пространства, так что около 167 байтов на строку. Таблица имеет три столбца: a VARCHAR(100), a DATETIME2(0)и a SMALLINT. Средняя длина текста в VARCHARполе составляет около 21,5, поэтому необработанные данные должны составлять около 32 байтов в строке: 22 + 2 для VARCHAR, 6 для DATETIME2и 2 для 16-разрядного целого числа.
Обратите внимание, что пространство выше - это только данные, а не индексы. Я использую значение, указанное в разделе Свойства | Хранение Генерал | Пространство данных.
Конечно, должны быть некоторые издержки, но 135 байтов на строку кажутся большими, особенно для большой таблицы. Почему это может быть? Кто-нибудь еще видел подобные множители? Какие факторы могут повлиять на количество необходимого дополнительного пространства?
Для сравнения я попытался создать таблицу с двумя INTполями и 1 M строк. Требуемое пространство данных составляло 16,4 МБ: 17 байтов на строку по сравнению с 8 байтами необработанных данных. В другой тестовой таблице с символом INTи, VARCHAR(100)заполненным тем же текстом, что и в реальной таблице, используется 39 байтов на строку (44 тыс. Строк), где я ожидал 28 плюс.
Таким образом, производственный стол имеет значительно больше накладных расходов. Это потому что оно больше? Я ожидал бы, что размеры индекса будут примерно N * log (N), но я не понимаю, почему пространство, необходимое для фактических данных, должно быть нелинейным.
Заранее спасибо за любые указатели!
РЕДАКТИРОВАТЬ:
Все поля перечислены NOT NULL. Реальная таблица имеет кластеризованный PK на VARCHARполе и DATETIME2поле в указанном порядке. Для двух тестов первым INTбыл (кластеризованный) PK.
Если это имеет значение: таблица представляет собой запись результатов пинга. Поля: URL, дата / время пинга и время ожидания в миллисекундах. Данные постоянно добавляются и никогда не обновляются, но данные периодически удаляются, чтобы сократить их до нескольких записей в час на URL.
РЕДАКТИРОВАТЬ:
Очень интересный ответ здесь предполагает, что для индекса с большим чтением и записью перестройка может быть не выгодной. В моем случае, занимаемое пространство - это проблема, но если производительность записи важнее, лучше использовать дряблые индексы.