Viene chiamato 1 = 2 per ogni riga?

Question

Ho alcuni sproc che necessitano di una tabella temporanea. Per non codificare i tipi di colonna (che sono varchar con una certa lunghezza), quindi non devo modificare le dichiarazioni quando lo schema della tabella di riferimento cambia (cioè i campi diventano più lunghi). Faccio questo (invece di creare una chiamata tabella):

select orderId 
into #sometmptbl 
from orders 
where 1=2 

Tuttavia, quando si esegue una showplan su questo in realtà sembra andare al tavolo/index: PIANO

query per DICHIARAZIONE 1 (in linea 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. 

totale stimato costi/O per dichiarazione 1 (at line 1): 632082.

significa 1 = 2 viene valutato per ogni ingresso nell'indice? C'è un modo per farlo in un tempo costante?

Aggiornamento:

Ecco il costo effettivo di I/O dopo il eseguire così sembra che l'attuale legge sono infatti 0 quindi non c'è alcun impatto sulle prestazioni:

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. 

Answer 1

Se si imposta statistiche io su, dovresti vedere zero letture logiche e fisiche. Può creare un piano per scansionare l'indice, ma sembra che non lo usi effettivamente.

Si consiglia di NON creare tabelle temporanee in questo modo in un ambiente di produzione ad alto volume. Ci sono problemi di blocco della tabella di sistema, oltre a un leggero calo di prestazioni (il tuo chilometraggio può variare). (anche l'attributo identity di una colonna viene riportato nella tabella temporanea).

Come scorciatoia: eseguo 1 = 2 in un tempdb..MyScratchTable esplicito e quindi utilizzo RapidSQL (o qualche altro strumento) per generare il DDL da quella tabella.

Se è un varchar, non ci dovrebbe essere alcun motivo per cui non è possibile standardizzare la lunghezza della colonna sul valore massimo e basta usarlo sempre.

Answer 2

Che cosa ti dà select orderId from orders where 1=2?

Potrebbe aver scelto l'indice per leggere i tipi di dati ecc., Mentre una query davvero banale (senza INTO) dovrebbe essere ottimizzata senza alcun accesso tabella/indice.