2009-10-23 25 views
7

¿Cuál es más rápido para millones de registros: Tabla permanente o Tablas temporales?Tabla vs Tabla temporal Rendimiento

Tengo que usarlo solo para 15 millones de registros. Una vez que se completa el proceso, eliminamos estos registros.

+2

Depende fuertemente de la situación. ¿Para qué lo quieres usar? –

+0

Permannent table. Se conecta al servidor y el millón de registros ya está allí, no se requiere ninguna acción, ¡subnano segundo tiempo! ... ¿Tal vez te gustaría elaborar sobre tu pregunta? –

+0

tengo que procesar 50 millones de registros. para esto tengo que crear una tabla Permanente/Temp. El escenario es: para proeccionar 50 millones de registros, ¿creo otro? /? tabla e Insertar en esta tabla. Luego aplico la prioridad como (Fname) y lo inserto en otra tabla Permanent \ temp y lo borro de la primera tabla. y aplica la prioridad 2 y luego el primer paso nuevamente. así que le pregunté a este qustion. por favor responde. – ManishKumar1980

Respuesta

14

En su situación utilizamos una tabla permanente llama una tabla de etapas. Este es un método común con grandes importaciones. De hecho, generalmente utilizamos dos tablas de etapas una con los datos sin procesar y otra con los datos limpios que facilitan la búsqueda de problemas con la alimentación (casi siempre son el resultado de nuevas y variadas formas que nuestros clientes nos envían datos no deseados, pero tenemos que poder demostrar eso). Además, evita problemas como tener que aumentar la temperatura temporal o causar problemas a otros usuarios que desean usar temp temporales pero tienen que esperar mientras crece, etc.

También puede usar SSIS y omitir la tabla de etapas (s)), pero creo que la capacidad de volver e investigar sin tener que volver a cargar una tabla de 50,000,000 es muy útil.

+0

SSIS es probablemente la mejor solución –

+2

+1 para señalar el beneficio agregado de ver los datos por etapas en caso de error: "También puede usar SSIS y omitir la (s) tabla (s) de preparación, pero creo que la capacidad de volver e investigar sin tener que volver a cargar una tabla de 50,000,000 es muy útil". – Mayo

2

La tabla permanente es más rápida si la estructura de la tabla debe ser 100% igual ya que no hay sobrecarga para asignar espacio y construir la tabla.

tabla Temp es más rápido en ciertos casos (por ejemplo, cuando no es necesario índices que están presentes en la mesa permanente de lo que ralentizaría inserciones/actualizaciones)

-1

tablas temporales están en la memoria (a menos que sean demasiado grandes), por lo que en teoría deberían ser REALMENTE rápidos. Pero generalmente no es así. Como regla general, trate de mantenerse alejado de las tablas temporales, a menos que esa sea la única solución. ¿Puede darnos más información sobre lo que está tratando de hacer? Probablemente se podría hacer con una consulta derivada

+7

Las variables de temperatura se almacenan en tablas de memoria no temporales. – ManishKumar1980

+1

No vi la pregunta es para MSSQL. En MySQL puede declarar una tabla de memoria temporal: 'CREATE TEMPORARY test ENGINE = MEMORY' – adamJLev

+1

Las variables de tabla aparentemente también se almacenan en tempdb - vea http://dba.stackexchange.com/questions/16385/whats-the-difference- between-a-temp-table-and-table-variable-in-sql-server/16386 # 16386 – flash

0

Yo personalmente usaría una tabla permanente y la truncaré antes de cada uso. En mi experiencia, es más fácil de entender/mantener. Sin embargo, mi mejor consejo para usted es probar ambos y ver cuál funciona mejor.

+2

Esto funcionará solo si el proceso es un singleton y no hay posibilidad de que se inicie otro proceso mientras tanto y que también requiera el uso de esa tabla. Tenemos procesos que importan muchos datos y no podríamos truncar una sola tabla porque se podrían ejecutar varios procesos al mismo tiempo. –

+0

Puede abordar eso utilizando una tabla permanente con una columna única para identificar el proceso de importación que trabaja con un conjunto particular de datos. Tenemos estos para las importaciones basadas en archivos impulsadas por el usuario (a diferencia de un lote nocturno donde truncar funciona bien). Podría considerar un proceso de limpieza para mantener el tamaño de la mesa bajo control. – Mayo

11

Si no utiliza tempdb, asegúrese de que el modelo de recuperación de la base de datos en la que está trabajando no esté configurado como "Completo". Esto causará mucha sobrecarga en esas inserciones de fila de 50M.

Idealmente, debe usar una base de datos de etapas, un modelo de recuperación simple, en RAID 10 si es posible, y dimensionarlo antes de tiempo para proporcionar suficiente espacio para todas sus operaciones. Desactivar crecimiento automático.

Uso INSERT ... CON (TABLOCK) para evitar la tala a nivel de fila:

INSERT INTO StagingTable WITH (TABLOCK) (.....) 
SELECT ..... 

Asimismo para BULK INSERT. Si suelta y vuelve a crear, cree su índice agrupado anterior para insertar. Si no puede, inserte primero en una tabla, luego inserte en otra tabla con la agrupación correcta y trunque la primera. Evite tamaños de lote pequeños en BULK INSERT si es posible. Lea atentamente la documentación BULK INSERT, ya que puede sabotear el rendimiento con las opciones incorrectas.

Evitar INSERTAR ... EXEC. Cada fila se registra.

Evite las ACTUALIZACIONES, a menos que necesite calcular los totales acumulados.En general, es más barato insertar de una tabla a otra, y luego truncar la primera tabla, que actualizar en su lugar. Ejecutar cálculos totales es la excepción, ya que se pueden hacer con una ACTUALIZACIÓN y variables para acumular valores entre filas.

Evite las variables de tabla para cualquier cosa, excepto las estructuras de control, ya que impiden la paralelización. No una su tabla de filas de 50M a una variable de tabla, use una tabla temporal en su lugar.

No tenga miedo de los cursores para la iteración. Utilice las variables de cursor y promulguelas con la palabra clave STATIC contra columnas de baja cardinalidad al principio del índice agrupado. Use esto para dividir las tablas grandes en fragmentos más manejables.

No intente hacer demasiado en ninguna declaración.

+0

Respuesta muy agradable y satisfactoria. Gracias a todos – ManishKumar1980