Производительность SQL 2005: порядок столбцов при смешивании varchars с типами int - PullRequest
Новая
       10

Производительность SQL 2005: порядок столбцов при смешивании varchars с типами int

0 голосов
/ 04 июня 2009

У меня есть такая таблица: 

create table SomeTable (
   tableKey    int identity(1,1) not null
,  foreignKey  int               not null
,  longDesc    nvarchar(max)     not null
,  shortName   varchar(100)      null
)

Мне нужно использовать shortName в предложении where: 

select 
    tableKey 
from 
    SomeTable 
where 
    foreignKey = @foreignKey 
and shortName = @shortName

и это должно быть быстро - в этой таблице миллионы строк. Могу ли я переместить его выше столбца longDesc и увидеть увеличение скорости? Я предполагаю, что база данных может просто перейти к правильному байтовому смещению, если столбцы имеют постоянный размер. Прыжок через столбец varchar должен повлечь за собой некоторое снижение производительности, да?

В качестве альтернативы, что если я сделал longDesc nchar (3784)? (Что должно заставить каждую строку заполнять страницу размером 8 КБ) Это увеличит скорость?

Я вижу один из ответов здесь намекает на то, что порядок имеет значение с точки зрения используемого пространства, но я не уверен, как это влияет на производительность.

Ответы [ 3 ]

4 голосов
/ 04 июня 2009

Для максимальной скорости вы должны создать постоянный вычисляемый столбец, такой как shortNameCrc = checkum (shortName), затем создать индекс для (foreignKey, checkum (shortName)) и include (shortName). Тогда вы бы запросили как где foreignKey = ForeignKey и shortNameCrc = контрольная сумма (@shortName) и shortName = shortName

Если SomeTable не кластеризован на tableKey, вы можете добавить tableKey в качестве включаемых столбцов. Если он кластеризован на tableKey, то значение уже присутствует в индексе покрытия.

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

Создание shortName char (100) может быть лучше, чем varchar (100). Учитывая неограниченный баран, я подозреваю, что это будет. В реальном мире это может зависеть от средней длины и вероятности пропуска кэша.

3 голосов
/ 04 июня 2009

Можно ли переместить его выше столбца longDesc и увидеть увеличение скорости?

Нет. IIRC, nvarchar (max) хранит только заполнитель / указатель с самой таблицей. Фактические данные перемещаются в другое место, именно по этой причине. По той же причине изменение размера вашего nvarchar (max) также не поможет.

Что вы должны сделать, это добавить индекс для ForeignKey, ShortName и TableKey Тогда ваш запрос может быть полностью удовлетворен индексом.

2 голосов
/ 04 июня 2009

Чтобы ускорить этот запрос, вы можете использовать индекс покрытия ( http://www.devx.com/dbzone/Article/29530), либо (foreignKey, shortName, tableKey) или же (shortName, foreignKey, tableKey)

Попробуйте оба варианта и посмотрите, что даст вам лучшую производительность

...