Чому помилка запиту з порожнім результатом задається в SQL Server 2012?

Під час виконання наступних запитів у MS SQL Server 2012 другий запит не вдається, але не перший. Крім того, якщо запускати без пунктів де обидва запити вийдуть з ладу. Я втрачаю, чому або не вдасться, оскільки обоє повинні мати порожні результати. Будь-яка допомога / розуміння цінується.

create table #temp
(id     int primary key)

create table #temp2
(id     int)

select 1/0
from #temp
where id = 1

select 1/0
from #temp2
where id = 1

Початковий погляд на плани виконання показує, що вираз 1/0визначений в операторах Compute Scalar:

Тепер, навіть незважаючи на те, що плани виконання дій починають виконуватися в крайній лівій частині, ітеративно виклику Openі GetRowметодів дочірніх ітераторів для повернення результатів, SQL Server 2005 і пізніше містить оптимізацію, згідно з якою вирази часто визначаються лише Обчислювальним скаляром, а оцінка відкладається до наступного Операція вимагає результату :

У цьому випадку результат вираження потрібен лише під час збирання рядка для повернення до клієнта (що можна подумати про те, що відбувається у зеленому SELECTзначку). За цією логікою відкладене оцінювання означало б, що вираз ніколи не оцінюється, оскільки жоден план не створює ряд повернення. Щоб трохи попрацювати над точкою, ні кластерний пошук пошуку, ні сканування таблиці не повертають рядка, тому немає рядка для збирання для повернення до клієнта.

Однак існує окрема оптимізація, згідно з якою деякі вирази можуть бути ідентифіковані як константи часу виконання і так оцінені один раз перед початком виконання запиту . У цьому випадку вказівку на цю ситуацію можна знайти в XML-шоу XML (План пошуку кластерних індексів зліва, План сканування таблиці справа):

Про основні механізми та про те, як вони можуть вплинути на ефективність, я писав у цій публікації в блозі . Використовуючи інформацію, надану там, ми можемо змінити перший запит, щоб обидва вирази були оцінені та кешовані перед початком виконання:

select 1/0 * CONVERT(integer, @@DBTS)
from #temp
where id = 1

select 1/0
from #temp2
where id = 1

Тепер перший план також містить посилання на постійний вираз, і обидва запити створюють повідомлення про помилку. XML для першого запиту містить:

Додаткова інформація: Обчислити скаляри, вирази та продуктивність

Я збираюся розумно здогадатися (і, напевно, залучатимуть гуру SQL Server, який міг би дати дійсно детальну відповідь).

Перший запит підходить до виконання як:

1. Скануйте індекс первинного ключа
2. Знайдіть значення в таблиці даних, необхідні для запиту

Він обирає цей шлях, оскільки у вас є whereпункт про первинний ключ. Він ніколи не потрапляє на другий крок, тому запит не виходить з ладу.

Другий не має первинного ключа, на якому він повинен працювати, тому він звертається до запиту як:

1. Зробити повну таблицю сканування даних та отримати необхідні значення

Одне з цих значень 1/0викликає проблему.

Це приклад оптимізації запиту SQL Server. Здебільшого це гарна річ. SQL Server перемістить умови з selectоперації сканування таблиці. Це часто економить кроки в оцінці запиту.

Але ця оптимізація не є непомітною справою. Насправді це, здається, порушує саму документацію на SQL Server , що говорить про те, що whereстаття оцінюється до початку select. Що ж, вони можуть мати якесь ерудитне пояснення, що це означає. Для більшості людей, однак, логічно обробляючи whereраніше, це selectозначатиме (серед іншого) "не створювати selectпомилки -клаузи на рядках, не повернених користувачеві".