2012-06-05 16 views
6

Tengo dos tablas:¿Cuándo es mejor no usar la unión interna?

table1 (id, name, connte) 
table2 (id, name, connte) 

Están conectados a través de table1.connte y table2.connte. Y cada uno de ellos contiene 100 registros.

Ahora si quiero eliminar un registro de tabla1 con id = 20 y sus correspondientes hijos en tabla2, es mejor hacer lo siguiente:

DELETE d1,d2 FROM table1 d1 INNER JOIN table2 d2 ON d1.connte= d2.connte WHERE d1.id = 20 

o el siguiente:

select connte from table1 where id = 20 
    --Store connte in a variable say aabc-- 
    delete from table2 where connte = aabc -> execute this first 
    delete from table1 where id = 20 -> execute this second 

Si solo hay un padre y un hijo para un registro que deseo eliminar (en este caso table1.id = 20), ¿no es costoso realizar una unión interna para toda la tabla?

Estoy ejecutando esta consulta desde JAVA (por lo que JDBC), por lo que es más caro (rendimiento) para ejecutar múltiples consultas o una unión interna, por la condición mencionada anteriormente?

NOTA: Suponiendo que no hay integridad referencial para las tablas. Entonces, no estoy usando la eliminación en cascada.

Respuesta

6

Probablemente sea más rápido hacerlo en una consulta, en lugar de hacerlo en dos. Básicamente, estás tratando de hacer optimizaciones tú mismo en lugar de dejar que DBMS lo haga, y en general DBMS es realmente bueno en este tipo de cosas.

Además, probablemente no tendrá que preocuparse por eliminar el rendimiento de las tablas tan pequeñas. 100 x 100 filas todavía es muy pequeño, por lo que su DBMS debería ser capaz de manejar esto sin ningún problema.

+0

Hmm..ok, pero ¿qué pasa cuando tengo, digamos, cien mil o un millón de registros? ¿Qué enfoque sería mejor para mi condición mencionada? – Harke

+0

Aún recomendaría dejar que el DBMS lo maneje. Sabe cómo hacer estas optimizaciones mejor de lo que usted probablemente pueda. – Oleksi

+0

¿Hay alguna forma en que pueda saber cómo funciona la unión interna? ¿No unirá dos mesas con millones de registros cada una, tomará tiempo? (incluso después de filtrar con la cláusula ON, existe la posibilidad de que haya muchos registros para unir) – Harke

3

La mejor manera de hacerlo es ejecutar un plan de explicación en ambas consultas en su DBMS, y el resultado le proporciona cosas como estimaciones de E/S, etc. En general, cada vez que tenga una pregunta sobre qué será más eficiente desde una perspectiva de DBMS, mirar los planes de consulta y las estimaciones de costos es su mejor arma.

SET showplan on 

debería funcionar en el servidor SQL. Aquí está el MSDN documentation, puede necesitar una sintaxis ligeramente diferente dependiendo de su DBMS. El cálculo del costo de E/S es probablemente lo que más le importa.

para MySQL, parece que se puede utilizar

EXPLAIN SELECT * FROM some_table 

Here is a tutorial en el análisis de consultas utilizando explicar.

En general, Oleksi está en lo cierto; la mayoría de los optimizadores son muy buenos en este tipo de cosas y crear manualmente una tabla temporal no te va a comprar mucho. Muchas veces el plan de consulta del optimizador implicará la creación de una tabla temporal.

Para una consulta de eliminación, una cosa importante para garantizar la velocidad es que su cláusula de eliminación utiliza parámetros indexados, por lo que no causa un análisis completo de la tabla. Explain/Showplan le indicará qué tipo de análisis está haciendo su consulta y qué índices está usando. Por lo general, desea evitar exploraciones de tablas completas.

1

En el servidor Sql no puede eliminar de dos tablas en una declaración de eliminación (sin un desencadenante o eliminación en cascada).

+0

Entonces, en mi caso (que no tiene integridad referencial y ningún activador), ¿solo la segunda condición es posible? – Harke

+0

sí, para el servidor SQl, Mysql puede ser diferente – HLGEM

0

¿Por qué no considerar el uso de claves externas y eliminaciones en cascada? Si configura su mesa correctamente, simplemente tendrá que eliminar el padre y luego el niño se encargará automáticamente. Ver este enlace When/Why to use Cascading in SQL Server?

Cuestiones relacionadas