He leido en varios post que el uso de UNION en varias tablas para buscar hace que valla lento el sql.
Entonces... ¿Como hago para buscar en varias tablas o simplemente manejarlas?
09-jul-2008, 12:01
|
#2 (permalink) |
 
Fecha de Ingreso: junio-2003
Ubicación: Santiago - Chile
Mensajes: 591
|
Respuesta: Rapidez y los UNION
El union sirve para mezclar dos o mas consultas SELECT en un unico conjunto de resultados, para buscar en varias tablas tienes simplemente que indicarle en el FROM y WHERE.
__________________
eft0's stuff! - http://eft0.nobody.cl |
|
|
|
09-jul-2008, 13:19
|
#4 (permalink) |
 Fecha de Ingreso: octubre-2007
Ubicación: Barcelona, España
Mensajes: 494
|
Respuesta: Rapidez y los UNION
Hola,
Cita:
Interesante afirmacion, habra que darle algunas vueltas......el uso de UNION en varias tablas para buscar hace que valla lento el sql.
En primer lugar hay que definir la diferencia entre UNION y UNION ALL, el primero tiene un costo adicional dado que elimina los registros repetidos despues de la union de datos de las dos tablas, esto no es una operacion trivial, a veces es preferible tener un par de registros duplicado que el costo de la operacion. En segundo lugar estan los filtros de busqueda y si tienen indices los campos, ya que cualquier motor (lo asumo) primero filtra por el WHERE y al resultado aplica la UNION. Por ejemplo
Código:
SQL> select * from t1;
ID DATA
---------- ------------------------------
1 data
2 data
3 data
4 data
5 data
SQL> select * from t2;
ID DATA
---------- ------------------------------
6 data
7 data
8 data
9 data
10 data
Código:
Tengo dos tablas, T1 y T2, donde T1 tiene un indice unique en el campo ID, que por cierto es el filtro del WHERE y T2 no tiene ningun indice, por lo tanto en la operacion 5 tengo el filtro WHERE ID = 6 utilizando el indice y en la operacion 6 tengo un FULL SCAN sobre T2 por no tener ninguno, al resultado se aplica la union, operacion 3, mientras que la operacion 2 es la adicional por no utilizar un UNION ALL, esto es, ordenar todos los registros para eliminar los repetidos.SQL> explain plan for 2 with s as ( 3 select id, data from t1 4 union 5 select id, data from t2 6 ) 7 select * from s where id = 6 8 / Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------ Plan hash value: 3372616832 -------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2 | 60 | 6 (34)| 00:00:01 | | 1 | VIEW | | 2 | 60 | 6 (34)| 00:00:01 | | 2 | SORT UNIQUE | | 2 | 60 | 6 (84)| 00:00:01 | | 3 | UNION-ALL | | | | | | | 4 | TABLE ACCESS BY INDEX ROWID| T1 | 1 | 30 | 1 (0)| 00:00:01 | |* 5 | INDEX UNIQUE SCAN | IND_T1_ID | 1 | | 0 (0)| 00:00:01 | |* 6 | TABLE ACCESS FULL | T2 | 1 | 30 | 3 (0)| 00:00:01 | -------------------------------------------------------------------------------------------- Como conclusion, si los campos a los que aplico los filtros estan indexados, no deberia haber problemas, entonces de donde viene la afirmacion, en mi opinion, el problema esta en que buscas en 2 o mas tablas la informacion que esta en una sola. Imagina el siguiente escenario, tengo 10 tablas, y dos opciones, 10 consultas SQL para buscar la informacion por tabla o 1 consulta SQL con la UNION de las 10, en el primer caso, si encuentro la informacion en la primera tabla, ya no tengo que recorrer las 9 restantes, y ahi es donde puede estar el costo adicional. Saludos |
|
|
|
 |
«
Tema Anterior
|
Próximo Tema
»
| Herramientas | |
| Desplegado | |
Mode Lineal
|
|
La Zona horaria es GMT -6. Ahora son las 20:35.
LinkBacks Enabled by vBSEO 3.1.0