GUID является первичным ключом, который также по умолчанию будет вашим ключом кластеризации, без сомнения будет вызывать большую фрагментацию - но, учитывая характер столбцов, varchar (max) будет регулярно отключаться от страницы в Хранение больших объектов и не хранится на странице, если оно не подходит, оставаясь в пределах ограничения 8060.
Таким образом, фрагментация не поможет при наличии GUID в качестве основного, если вы также сделали его кластеризованным - вы можете проверить уровни фрагментации с помощью DMV sys.dm_db_index_physical_stats
Я бы не думал, что фрагментация - это действительно проблема, если средний объем данных на строку не высок, например регулярно выше 8к.
Если это так, ... фрагментация начинает болеть. В худшем случае это 1 строка на страницу, 7 тыс. Операций ввода-вывода, что не является идеальным, но при среднем 100 тыс. На хранилище больших объектов можно рассмотреть дополнительные 87 тыс. Операций ввода-вывода, и порядок записи данных и т. Д. Может привести к тому, что Предполагается, что это будет последовательное сканирование таблицы (и диска), превращающееся в массовый случайный ввод-вывод, когда диск перемещается вперед и назад между страницей с указателем строки + LOB и страницами LOB.
К этому добавляется вероятность того, что GUID является ключом кластеризации, поэтому он не может даже сканировать страницы данных без небольшого движения головки диска.
Я также должен согласиться с Эрихом, что количество данных, которые вы пытаетесь сместить по проводам, вызовет довольно большую задержку при недостаточном соединении, и вам следует обратить внимание на правильную фильтрацию данных на уровне сервера с помощью пейджинга или подходящих запросов. ,
Я знаю, что вы пытаетесь предварительно кэшировать данные, которые могут работать время от времени - но они выполняются на таком большом объекте, это указывает на то, что что-то еще не так, и вы исправляете неправильную проблему.
A.