2008-10-20 19 views
5

Tengo un script que necesita extraer datos temporalmente para realizar operaciones adicionales en él, pero luego no necesita almacenarlo más después de que se haya ejecutado el script. Actualmente tengo los datos en cuestión en una serie de tablas locales temporales (CREATE TABLE #table), que luego se eliminan a medida que se completa su uso. Estaba considerando cambiar a tablas físicas, tratadas de la misma manera (tabla CREATE TABLE), si hubiera una mejora en la velocidad de la secuencia de comandos (u otras ventajas, ¿tal vez?).¿Cuál es la velocidad comparativa de las tablas temporales con las tablas físicas en SQL?

... Entonces, ¿hay una diferencia en el rendimiento, entre tablas temporales y tablas físicas? Según lo que estoy leyendo, las tablas temporales son solo tablas físicas que solo la sesión que ejecuta el script puede ver (reduciendo los problemas de bloqueo).

EDITAR: Debo señalar que estoy hablando de tablas físicas vs. tablas temporales. Hay mucha información disponible sobre tablas temporales vs. variables de tabla, p. Ej. http://sqlnerd.blogspot.com/2005/09/temp-tables-vs-table-variables.html.

Respuesta

1

Las tablas temporales son un gran NO en SQL Server.

  • Provocan las recompilaciones del plan de consulta, que es costoso.
  • Crear y eliminar la tabla también son operaciones costosas que está agregando a su proceso.
  • Si hay una gran cantidad de datos que van a los datos temporales, sus operaciones serán lentas debido a la falta de índices. PUEDE crear índices en tablas temporales. Pero nunca recomendaré una tabla temporal para nada con una gran cantidad de registros.

Su otro enfoque: Crear y soltar tablas regulares solo crea la misma sobrecarga.

Otro enfoque: el uso de tablas existentes, el aumento de las filas con una columna adicional para diferenciar qué filas pertenecen a cada usuario/sesión podría ser utilizado. Elimina la carga de crear/eliminar las tablas pero, entonces, tendrá que ser paranoico con el código que genera el valor para diferenciar las filas Y deberá desarrollar una forma de mantener la tabla para aquellos casos en que una sesión finalizó prematuramente y hay sobras (filas que no se eliminaron al final del proceso).

Te recomiendo que reconsideres tu estrategia de proceso. Algunas alternativas son tan sencillas como usar consultas correlacionadas, tablas derivadas o variables de tabla. Echar un vistazo a: http://www.sql-server-performance.com/articles/per/temp_tables_vs_variables_p1.aspx


Editar: El enfoque de crear y eliminar tablas regulares y el enfoque de la reutilización de una mesa normal augumented con un campo adicional: Ambas herramientas generarán recopilaciones del plan de consulta porque la cantidad de datos cambiado activará la reevaluación de las estadísticas de la tabla. Una vez más, su mejor enfoque es encontrar formas alternativas de procesar sus datos.

+5

-1 Las tablas de #temp probablemente serán mejores en este escenario. [Vea esta respuesta para obtener una explicación] (http://stackoverflow.com/questions/3175427/sql-server-temporary-vs-physical-tables/3175531#3175531). Además 'tempdb' tiene optimizaciones de registro en comparación con las bases de datos regulares. Las variables de tabla se almacenan exactamente igual que las tablas temporales, por lo que la sugerencia no tiene sentido. Ese artículo al que se vincula es completamente incorrecto sobre el registro de transacciones para variables de tabla también. –

0

Para MySql al menos, el único ahorro de tiempo que obtendrá es el ahorro de tiempo en la creación de la tabla temporal. AFAIK todas las tablas son tratadas de la misma manera en el disco, simplemente se van al final de la sesión. Esto es lo que he visto en la práctica también. De nuevo, esto es mysql 4.x y 5.x

0

No estoy 100% seguro de esto, pero creo que las variables de tabla están estrictamente en la memoria, pero las tablas temporales residen en tempdb, que se almacena en el disco. Esto está usando SQL Server, no estoy seguro de cuán consistentes son los diferentes RDMS sobre esto.

1

¿Qué tipo de operaciones de datos está haciendo y con qué datos está trabajando?

Me quedaría con las tablas temporales: para grandes conjuntos de datos, siempre he encontrado que es, con mucho, la mejor manera de hacerlo, y no solo en SQL Server. Puede probar una tabla temporal global (CREATE TABLE ## tablename), que dura más allá del alcance de la declaración de creación.

De SQL Server Books Online (2005):

Si crea los ## empleados globales tabla temporales, cualquier usuario en la base de datos puede trabajar con esta tabla. Si ningún otro usuario trabaja con esta tabla después de crearla, la tabla es borrada cuando se desconecta. Si otro usuario trabaja con la tabla después de crearlo, SQL Server lo elimina después de desconectarse y después de que todas las demás sesiones ya no lo usen .

1

Una cosa a considerar es si puede contar con un solo usuario que ejecuta este proceso a la vez. Si tiene usuarios simultáneos, entonces la opción de tabla normal podría tener interferencia. La tabla temporal puede ser única para el usuario.

Cuestiones relacionadas