Стратегии проверки ISNULL на полях varbinary? - PullRequest
Новая
       21

Стратегии проверки ISNULL на полях varbinary?

15 голосов
/ 23 сентября 2010

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

select top 100 * from Files where Content is null

Я подозреваю, что это медленно, потому что

  1. Нужно извлечь весь двоичный файл, и
  2. Он не проиндексирован (varbinary не может бытьчасть нормального индекса)

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

Одним из возможных решений, о котором я подумал, является создание вычисляемого столбца с индексом : 

alter table Files
add ContentLength as ISNULL(DATALENGTH(Content),0) persisted

CREATE NONCLUSTERED INDEX [IX_Files_ContentLength] ON [dbo].[Files] 
(
    [ContentLength] ASC
)

select top 100 * from Files where ContentLength = 0

Это правильная стратегия?Какие есть другие способы эффективного запроса, когда задействованы двоичные поля?

Ответы [ 2 ]

9 голосов
/ 23 сентября 2010

Я думаю, что это медленно, потому что столбец varbinary не проиндексирован (и не может быть). Следовательно, ваш подход к использованию вычисляемого (и индексированного) столбца верен.

Однако вместо этого я бы использовал ISNULL(DATALENGTH(Content), -1), чтобы вы могли различать длину 0 и NULL. Или просто используйте DATALENGTH(Content). Я имею в виду, что Microsoft SQL Server - это не Oracle, где пустая строка совпадает с NULL.

2 голосов
/ 15 сентября 2016

У нас была похожая проблема при поиске строк, в которых значение varbinary не было нулевым. Для нас решением было обновить статистику для базы данных: 

exec sp_updatestats

После этого запросы выполнялись намного быстрее.

...