2010-07-12 6 views
5

Tengo algunos sprocs que necesitan una tabla temporal. Para no codificar los tipos de columnas (que son varchar con algo de longitud) no tengo que cambiar las declaraciones cuando el esquema de la tabla de referencia cambia (es decir, los campos se alargan). Lo hago (en lugar de crear una llamada de tabla):¿Se llama a 1 = 2 para cada fila?

select orderId 
into #sometmptbl 
from orders 
where 1=2 

Sin embargo, cuando se hace un plan de presentación en esta realidad parece ir a la mesa/index: PLAN

CONSULTA dE ESTADO 1 (en la línea 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. 

coste total estimado de E/S para la declaración 1 (en la línea 1): 632082.

¿Quiere esto decir 1 = 2 consigue evaluados para cada entrada en el índice? ¿Hay alguna manera de hacer esto en un tiempo constante?

actualización:

Aquí está el costo real de E/S después de la EJECUTAR lo que parece que el actual lecturas se han hecho 0 lo que no hay impacto en el rendimiento:

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. 

Respuesta

4

Si establece estadísticas io en, debería ver cero lecturas lógicas y físicas. Puede crear un plan para escanear el índice, pero parece que no lo usa realmente.

Recomendaría NO crear tablas temporales de esta manera en un entorno de producción de gran volumen. Hay problemas de bloqueo de la tabla del sistema, así como un leve golpe de rendimiento (su kilometraje puede variar). (también el atributo de identidad de una columna se transfiere a la tabla temporal).

Como un acceso directo: hago el 1 = 2 en una tempdb..MyScratchTable explícita, y luego uso RapidSQL (o alguna otra herramienta), para generar el DDL desde esa tabla de cero.

Si es un varchar, no debería haber ningún motivo por el que no pueda estandarizar la longitud de la columna en el valor máximo y simplemente usar ese everwhere.

+0

Parece que tiene razón, las lecturas reales son 0 – naumcho

0

¿Qué le proporciona select orderId from orders where 1=2?

Puede haber elegido el índice para leer los tipos de datos, etc., mientras que una consulta realmente trivial (sin INTO) debe optimizarse sin ningún acceso de tabla/índice.

Cuestiones relacionadas