Размер строки влияет на производительность SQL Server

24 Мая 2016 Программирование
3 0

В MS SQL Server ты можешь создавать поля типа varchar(max) и с точки зрения производительности это чуть лучше, чем text. Если размер текста в поле меньше 8k, то сервер будет пытаться сохранить его вместе с остальными данным в той же странице. Если больше 8 кило, то данные точно уйдут в отдельное хранилище, что отрицательно скажется на производительности, если массово выбирать данные. 

Обычно для запросов, которые возвращают данные для сеток или списков данных,  не нужно возвращать текстовые поля. Трудно представить себе сетку, где будет большой текст. Разве что блоги. Например, у меня запись блога состоит из двух текстовых полей - первое показывается в списке, а второе, когда вы открываете саму статью. Не знаю как MySQL, но в MS SQL Server эти текстовые поля притормаживали бы запросы. 

За счёт того, что я показываю на блоге записи постранично, максимум 10 записей на странице, то потри не смертельны, но на нагрузке на сервер это все же сказывается. Для сайтов с большим трафиком я бы все же сделал поле Intro, которое у меня отображается в списке не текстовым, а varchar. 1000 символов должно хватить с головой. Главное не выполнять запросов типа SELECT *, но к сожалению этим грешат многие программисты. Да и я сам такой же.

Об этом поведении я знал уже давно и я стараюсь использовать такие большие стоки только когда это действительно необходимо. Но на этой неделе я работал над тормозным запросом, у которого были все необходимые индексы, но он выполнился 12 секунд. Ну да, он возвращал 17 тысяч строк, но все равно 12 секунд это много. 

Я потратил целый день на этот запрос и в шоке узнал, что проблемой были nvarchar поля размером в 512 символов. Причём эта таблица была совершенно пустая. Я попробовал обновить статистику, перестроить индексы, но ничего не помогало. Хотя какую статистику обновлять на пустой таблице? Я обновил статистику на все таблицы - не помогло. Причём план выполнения не показывает, что вина именно в этой пустой таблице, он показывает, что данные тормозят в Worktable, где обрабатываются данные с нескольких таблиц. 

Просто для прикола - создаю копию этой таблицы, но запрос все равно тормозит. Создаю ещё одну копию, но на этот раз измеряю размер полей с 512 символов на 112. Скорость выполнения взлетает и запрос работает уже не 12 секунд, а 3 секунды. Попробовал с таблицей с размером полей в 200 символов и запрос снова начал тормозить.  

Очень странно, я надеялся, что оптимизатор SQL сервера увидит, что таблица пустая и не будет тупить. Хотя... В чем то это даже хорошо, ведь это у меня она пустая, а на рабочем сервере пользователи могут занести туда данные и потом вычисляй в чем проблема. 

В общем, с удивлением узнал, что даже при пересечении границы размера поля в 200 символов, SQL Server может начать тормозить, причем очень сильно. До этого не сталкивался с такой проблемой. 

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым