У меня есть таблица с более чем 100 млн строк. Мы наблюдаем очень низкую производительность запросов по мере роста данных. Я заметил, что размер строки довольно большой (10190), и я думаю, что это влияет на индексы / производительность индекса.
в таблице есть несколько столбцов, для которых заданы неправильные типы данных (много целых чисел, для которых более подходящими являются smallints и т. д.). Я пошел и обновил таблицу, чтобы изменить то, что мог.
Исходный размер строки - 10190, и мне удалось уменьшить его до 10090, изменив целые значения на smallint или tinyint.
Есть два столбца, установленных для varchar (2048). Я изменил их на varchar (max), и размер строки уменьшился до 6000.
Я использовал найденные здесь запросы http://www.sqlservercentral.com/Forums/Topic226699-5-1.aspx чтобы получить размер строки.
Мой вопрос: помогает ли изменение столбцов varchar (2048) на varchar (max) индексации / производительности, когда эти столбцы не используются часто? Как насчет того, чтобы размер строки был меньше 8000?
Принципиально нет разницы между VARCHAR(2048) и VARCHAR(MAX). Один подвержен переполнению в блоке распределения «переполнение строки», другой - в блоке распределения BLOB, см. Организация таблиц и указателей. Настройка по умолчанию large value types out of row параметр таблицы равен 0, поэтому, если он не был изменен, VARCHAR(MAX) по возможности останется в ряду, как и VARCHAR(2048) бы.
Я бы рекомендовал бегать sys.dm_db_index_physical_stats и получение фактического максимального, минимального и среднего размера строки, а также avg_page_space_used_in_percent. Это даст более точное представление об истинных размерах строк, а не о теоретических заявленных размерах.
Первым делом я бы проверил кластерный индекс. При использовании составного индекса следует установить что-то узкое, один столбец или как можно меньше столбцов. В идеале он должен иметь значение, которое может быть последовательным, например bigint, а не uniqueIdentifier. При использовании кластеризованного индекса uniqueIdentifier некоторые люди видят улучшение производительности за счет добавления кластеризованного индекса bigint и сохранения uniqueIdentifier в качестве уникального индекса.
SSMS иногда содержит полезную информацию, в которой могут отсутствовать индексы:
http://msdn.microsoft.com/en-us/library/ms345524%28v=SQL.100%29.aspx
Следующим шагом будет анализ запросов. Выясните, какие запросы занимают больше всего времени, и определите, попадают ли они в закрывающие индексы или выполняют сканирование таблиц. Вы можете опубликовать некоторые запросы sql и сведения о существующих индексах.
Запросы написаны так, что они запрашивают только те данные, которые им нужны, то есть без SELECT *?
Я бы проверил общую настройку SQL-сервера, убедился, что конфигурация соответствует рекомендуемой практике (см. Отличную контрольный список ); затем, возможно, запустите какой-нибудь perfmon, чтобы увидеть ваши узкие места, сначала проверьте длину дисковой очереди.