Условный поток SQL Server

Я бы переписал тест как

IF CASE
     WHEN EXISTS (SELECT ...) THEN CASE
                                   WHEN EXISTS (SELECT ...) THEN 1
                                 END
   END = 1  

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

В моих крайне ограниченных тестах, приведенных ниже, при тестировании казалось верным следующее:

1. EXISTS AND EXISTS

Версия EXISTS AND EXISTS кажется наиболее проблемной. Это связывает вместе некоторые внешние полусоединения. Ни в одном из случаев он не менял порядок тестов, чтобы попытаться сначала провести более дешевый (проблема, обсуждаемая во второй половине этого сообщения в блоге). В версии IF ... это не имело бы никакого значения, если бы она была, потому что она не замыкалась. Однако, когда этот комбинированный предикат помещается в предложение WHERE, план изменяется, и он выполняет короткое замыкание, так что перестановка могла быть полезной.

/*All tests are testing "If False And False"*/

IF EXISTS(SELECT COUNT(*) FROM master..spt_monitor HAVING COUNT(*)=2)  
AND EXISTS (SELECT COUNT(*) FROM master..spt_values HAVING COUNT(*)=1)
PRINT 'Y'
/*
Table 'spt_values'. Scan count 1, logical reads 9
Table 'spt_monitor'. Scan count 1, logical reads 1
*/

IF EXISTS (SELECT COUNT(*) FROM master..spt_values HAVING COUNT(*)=1) 
AND EXISTS(SELECT COUNT(*) FROM master..spt_monitor HAVING COUNT(*)=2) 
PRINT 'Y'
/*
Table 'spt_monitor'. Scan count 1, logical reads 1
Table 'spt_values'. Scan count 1, logical reads 9
*/

SELECT 1
WHERE  EXISTS(SELECT COUNT(*) FROM master..spt_monitor HAVING COUNT(*)=2)  
AND EXISTS (SELECT COUNT(*) FROM master..spt_values HAVING COUNT(*)=1)
/*
Table 'Worktable'. Scan count 0, logical reads 0
Table 'spt_monitor'. Scan count 1, logical reads 1
*/

SELECT 1
WHERE  EXISTS (SELECT COUNT(*) FROM master..spt_values HAVING COUNT(*)=1) 
AND EXISTS(SELECT COUNT(*) FROM master..spt_monitor HAVING COUNT(*)=2) 
/*
Table 'Worktable'. Scan count 0, logical reads 0
Table 'spt_values'. Scan count 1, logical reads 9

*/

Планы на все это кажутся очень похожими. Причина разницы в поведении между версией SELECT 1 WHERE ... и версией IF ... заключается в том, что для первой версии, если условие ложно, то правильным поведением является отсутствие результата, поэтому она просто связывает OUTER SEMI JOINS, а если одна из них ложна, то нулевые строки несут вперед к следующему.

Однако версия IF всегда должна возвращать результат 1 или ноль. Этот план использует пробный столбец во внешних соединениях и устанавливает для него значение false, если тест EXISTS не пройден (а не просто отбрасывает строку). Это означает, что в следующее соединение всегда подается 1 строка, и оно всегда выполняется.

Версия CASE имеет очень похожий план, но использует предикат PASSTHRU, который используется для пропуска выполнения JOIN, если предыдущее THEN условие не было выполнено. Я не уверен, почему комбинированные ANDs не использовали бы тот же подход.

2. EXISTS OR EXISTS

Версия EXISTS OR EXISTS использовала оператор конкатенации (UNION ALL) в качестве внутреннего ввода для внешнего полусоединения. Такое расположение означает, что он может прекратить запрашивать строки с внутренней стороны, как только будет возвращена первая (т. Е. Может эффективно закоротить). Все 4 запроса закончились тем же планом, в котором сначала оценивался более дешевый предикат.

/*All tests are testing "If True Or True"*/

IF EXISTS(SELECT COUNT(*) FROM master..spt_monitor HAVING COUNT(*)=1)  
OR EXISTS (SELECT COUNT(*) FROM master..spt_values HAVING COUNT(*)<>1)
PRINT 'Y'
/*
Table 'Worktable'. Scan count 0, logical reads 0
Table 'spt_monitor'. Scan count 1, logical reads 1
*/

IF EXISTS (SELECT COUNT(*) FROM master..spt_values HAVING COUNT(*)<>1) 
OR EXISTS(SELECT COUNT(*) FROM master..spt_monitor HAVING COUNT(*)= 1) 
PRINT 'Y'
/*
Table 'Worktable'. Scan count 0, logical reads 0
Table 'spt_monitor'. Scan count 1, logical reads 1
*/

SELECT 1
WHERE  EXISTS(SELECT COUNT(*) FROM master..spt_monitor HAVING COUNT(*)= 1)  
OR EXISTS (SELECT COUNT(*) FROM master..spt_values HAVING COUNT(*)<>1)
/*
Table 'Worktable'. Scan count 0, logical reads 0
Table 'spt_monitor'. Scan count 1, logical reads 1
*/

SELECT 1
WHERE  EXISTS (SELECT COUNT(*) FROM master..spt_values HAVING COUNT(*)<>1) 
OR EXISTS(SELECT COUNT(*) FROM master..spt_monitor HAVING COUNT(*)=1) 
/*
Table 'Worktable'. Scan count 0, logical reads 0
Table 'spt_monitor'. Scan count 1, logical reads 1
*/

3. Добавление ELSE

Мне действительно пришло в голову попробовать закон Де Моргана преобразовать AND в OR и посмотреть, имеет ли это какое-либо значение. Преобразование первого запроса дает

IF NOT ((NOT EXISTS(SELECT COUNT(*) FROM master..spt_monitor HAVING COUNT(*)=2)  
OR NOT EXISTS (SELECT COUNT(*) FROM master..spt_values HAVING COUNT(*)=1)))
PRINT 'Y'
ELSE
PRINT 'N'
/*
Table 'spt_monitor'. Scan count 1, logical reads 1
Table 'spt_values'. Scan count 1, logical reads 9
*/

Так что это по-прежнему не влияет на поведение при коротком замыкании. Однако, если вы удалите NOT и измените порядок условий IF ... ELSE, он теперь делает короткое замыкание!

IF (NOT EXISTS(SELECT COUNT(*) FROM master..spt_monitor HAVING COUNT(*)=2)  
OR NOT EXISTS (SELECT COUNT(*) FROM master..spt_values HAVING COUNT(*)=1))
PRINT 'N'
ELSE
PRINT 'Y'
/*
Table 'Worktable'. Scan count 0, logical reads 0
Table 'spt_monitor'. Scan count 1, logical reads 1
*/

Я считаю, что вы можете положиться на короткое замыкание операторов IF в большинстве, если не во всех, современных языках. Вы можете попробовать проверить, поставив сначала истинное условие и заменив второе условие на 1/0, что даст вам деление на ноль ошибки, если короткого замыкания не происходит, например:

IF 1>0 OR 1/0 BEGIN
  PRINT 'Short Circuited'
END

Если вы этому не доверяете, вы всегда можете переписать свой запрос так:

IF EXISTS(SELECT...) BEGIN
  IF EXISTS(SELECT...) BEGIN
    ...
  END
END

Если я выполню запрос с И, даже тогда, обе таблицы будут доступны

УСТАНОВИТЬ СТАТИСТИКУ ВВОДА-ВЫВОДА НА ЕСЛИ СУЩЕСТВУЕТ (ВЫБРАТЬ * из master..spt_values, где [name] = 'rpcc') и СУЩЕСТВУЕТ (ВЫБРАТЬ * из master..spt_monitor, где pack_sent = 5235252) ПЕЧАТЬ 'Y'

Таблица spt_monitor. Счетчик сканирований 1, логических чтений 1, физических чтений 0, упреждающих чтений 0, логических чтений lob 0, физических чтений lob 0, упреждающих чтений lob 0. Таблица spt_values. Счетчик сканирования 1, логических чтений 17, физических чтений 0, упреждающих чтений 0, логических чтений lob 0, физических чтений lob 0, упреждающих чтений lob 0.

Я беру следующие цитаты из следующей записи блога о sqlteam:

Как SQL Server прерывает оценку условия WHERE

Это происходит тогда, когда хочется, но не так, как вы сразу думаете.

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

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

Короткое замыкание SQL Server? < / а>

Было интересное наблюдение. У меня две таблицы tbla и tblb. tbla имеет первичный ключ (idvalue), который используется в качестве внешнего ключа в tblb. У обоих есть строка с idvalue = 1, но нет строки с idvalue, равным -1. Теперь в запросе ниже используется только одна таблица

select 1
where exists
(select 1 from tbla where idvalue = -1)
and exists (select 1 from tblb where idvalue= 1)

Дает

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'tbla'. Scan count 0, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Это очевидно, потому что оптимизатор знает, что, поскольку существует связь первичный ключ-внешний ключ, поэтому, если значение отсутствует в tbla, оно никогда не может присутствовать в tblb. Таким образом, оптимизатор примет решение о времени выполнения, при котором поиск по tblb не требуется.

Однако, если я напишу запрос как

select 1
where exists
(select 1 from tbla where idvalue = 1)
and exists (select 1 from tblb where idvalue= -1)

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

Однако в обоих случаях фактический план выполнения показывает поиск как по tbla, так и по tblb. Мне это кажется странным. Есть мысли по этому поводу?

Нет.

Я только что тестировал SQL Server 2008, и если первая оценка не удалась, блок IF сразу же пропускается.

Это очень легко проверить.

Для первой оценки сделайте что-нибудь вроде IF 1=0, а для второй сделайте что-нибудь, а затем покажите фактический план выполнения. В моем случае он выполняет только постоянное сканирование для оценки этих констант.

Вы можете предотвратить второе сканирование, выполнив следующие действия:

declare @test bit
select @test = case when exists(select 1...) then 1 else 0 end
if @test = 1
begin
    --1st test passed
    select @test = case when exists(select 2...) then 1 else 0 end
end
if @test = 1
begin
    print 'both exists passed'
end