2016-10-11 4 views
11

У меня есть таблица с двумя значениями:SQL переменная занимает больше времени, чтобы вернуться, чем статическое значение

ciid, businessdate 

ciid является первичным ключом, и имеет автоматическое приращение включено. businessdate (datetime) вставляется другим процессом.

данные следующие запросы:

select top(1) ciid, businessdate 
from checkitemsales 
where businessdate='10/9/16 00:00:00:000' 

Это занимает всего 1,2 секунды, чтобы вернуться, в то время как этот запрос:

declare @var1 datetime 

set @var1='10/9/16 00:00:00:000' 

select top(1) ciid, businessdate 
from checkitemsales 
where businessdate = @var1 

занимает более 5,6 секунд, чтобы вернуться.

может ли кто-нибудь сказать мне, что я делаю неправильно?

+1

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

+0

, конечно, метод 2 занимает больше времени по сравнению с методом 1, потому что каждый раз, когда запрашиваются данные, ему нужно обратиться к этому «set @ var1 = '10/9/16 00: 00: 00: 000 ' " data – KyLim

+0

Проверьте планы запросов. Может быть, в кэше есть плохой план для второго запроса. – Blorgbeard

ответ

1
declare @var1 datetime 

set @var1='10/9/16 00:00:00:000' 

select top(1) ciid, businessdate 
from checkitemsales 
where (businessdate = @var1) option (recompile) 

попробовать это, и дайте мне знать результат, может быть быстрее

+0

Msg 156, Level 15, State 1. Неверный синтаксис рядом с ключевым словом «option». (Линия 7) – kloodge

+0

объявить @ var1 DateTime набор @ var1 = '10/9/16 00: 00: 00: 000' выберите верхний (1) ciid, businessdate из checkitemsales где (businessdate = @ var1) Опция (перекомпилировать) закончилась менее чем за секунду! – kloodge

+0

@kloodge только второй раз, hahahaa, попробовал мои лучшие – KyLim

4

Это называется параметр нюхают

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

Вы можете избежать этого различными способами. один

Пересобираем

Вы можете добавить option(Recompile) в запросе, так что каждый раз, когда запрос составлен новый план выполнения будет сгенерирован

select top(1) ciid, businessdate 
from checkitemsales 
where businessdate = @var1 
OPTION (RECOMPILE); 

Недостатки

  • Запросы часто выполняются.
  • Ресурсы центрального процессора ограничены.
  • Возможна некоторая разница в производительности запросов.

Другие методы

  • Оптимизировать Value
  • Оптимизировать для Неизвестных
  • Исключения

Проверьте ниже статьи о деталях всех вышеперечисленных методов

sp_BlitzCache™ Result: Parameter Sniffing

Parameter Sniffing

0

Вы можете попробовать этот подход:

declare @var1 datetime 
set @var1='10/9/16 00:00:00:000' 

declare @cmd varchar(max) = 'select top(1) ciid, businessdate 
from #table 
where businessdate = ''' + CONVERT(VARCHAR(10), @var1, 1) + ' ' + convert(VARCHAR(12), @var1, 114) + '''' 

EXEC (@cmd) 
Смежные вопросы