Где 1=2 требуются каждая строка?

У меня есть некоторые sprocs, которым нужна временная таблица. Чтобы не к hardcode типы столбца (которые являются varchar с некоторой длиной), таким образом, я не должен изменять объявления, когда ссылочная схема таблицы изменяется (т.е. поля становятся длиннее) я делаю это (вместо создать вызова таблицы):

select orderId
into #sometmptbl
from orders
where 1=2

Однако, когда Вы делаете план выполнения на этом, это на самом деле, кажется, идет в таблицу/индекс:

ПЛАН ЗАПРОСОВ ДЛЯ ОПЕРАТОРА 1 (в строке 1).

STEP 1
    The type of query is CREATE TABLE.

STEP 2
    The type of query is INSERT.
    The update mode is direct.

    FROM TABLE
        orders
    Nested iteration.
    Index : orders_idx1
    Forward scan.
    Positioning at index start.
    Index contains all needed columns. Base table will not be read.
    Using I/O Size 2 Kbytes for index leaf pages.
    With LRU Buffer Replacement Strategy for index leaf pages.
    TO TABLE
        #sometmptbl
    Using I/O Size 2 Kbytes for data pages.

Общий предполагаемый ввод-вывод стоится за оператор 1 (в строке 1): 632082.

Это означает 1=2, оценен для каждой записи в индексе? Существует ли способ сделать это в постоянное время?

Обновление:

Вот фактическая стоимость ввода-вывода после выполнения, таким образом, похоже, что фактические чтения действительно 0, таким образом, нет никакого влияния производительности:

Table: orders scan count 0, logical reads: (regular=0 apf=0 total=0), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #sometmptbl_____00002860018595346 scan count 0, logical reads: (regular=1 apf=0 total=1), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total actual I/O cost for this command: 2.
Total writes for this command: 3
0 row(s) affected.
5
задан naumcho 12 July 2010 в 19:19
поделиться

2 ответа

Если вы установите statistics io on, вы должны увидеть нулевые логические и физические чтения. Он может создать план сканирования индекса, но, похоже, фактически не использует его.

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

В качестве короткого пути - я делаю 1=2 в явной tempdb..MyScratchTable, а затем использую RapidSQL (или другой инструмент), чтобы сгенерировать DDL из этой временной таблицы.

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

4
ответ дан 15 December 2019 в 00:48
поделиться

Что выбирает orderId из заказов, где 1 = 2 дает вам?

Возможно, он выбрал индекс для чтения типов данных и т. Д., Тогда как действительно тривиальный запрос ( без INTO) следует оптимизировать без доступа к таблицам / индексам вообще.

0
ответ дан 15 December 2019 в 00:48
поделиться
Другие вопросы по тегам:

Похожие вопросы: