FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Optimizando Consulta
Hola Amigos:
Es un placer siempre saber como están y como siempre aprovechando de sus conocimiento avanzados me encargo de sacar provecho del mismo: Tengo esta consulta la cual en mi db en Firebird 2.5.7.27050 de Desarrollo con diferencia de 150 mil registros a la de producción noto de no es el mismo rendimiento a pesar que ya se realizaron los indexados correcto en cada tabla aquí mostrada no veo porque la direrencia en hacer la misma consulta en tiempo de traer los datos es significativamente amplio una de la otra: Código:
Base de Datos de producción Prepare : 16 ms Execute : 0 ms Avg fetch time: 0 ms Memory Usage ------------------------------------------------ Current: 1.11 MB Max : 1.12 MB Buffers: 75 Database Operations ------------------------------------------------ Reads : 63417 Writes : 4 Fetches: 15903532 Plan: ------------------------------------------------ PLAN SORT (JOIN (FAC_CAJA NATURAL, CAJAS INDEX (RDB$PRIMARY77), FACTURAS_VENTAS INDEX (RDB$PRIMARY45), FAC_CLIENTE INDEX (IDX_FAC_CLIENTE), CLIENTES INDEX (RDB$PRIMARY85))) Table Operations: +--------------------------+-----------+-----------+-----------+-----------+-----------+ | Table Name | Index | Non-Index | Updates | Deletes | Inserts | | | reads | reads | | | | +--------------------------+-----------+-----------+-----------+-----------+-----------+ | FAC_CAJA| 0 | 1,321,933 | 0 | 0 | 0 | | FACTURAS_VENTAS| 1,321,933 | 0 | 0 | 0 | 0 | | FAC_CLIENTE| 52 | 0 | 0 | 0 | 0 | | CAJAS| 1,321,933 | 0 | 0 | 0 | 0 | | CLIENTES| 52 | 0 | 0 | 0 | 0 | +--------------------------+-----------+-----------+-----------+-----------+-----------+ Código:
Query Performance ------------------------------------------------ Prepare : 0 ms Execute : 0 ms Avg fetch time: 0 ms Memory Usage ------------------------------------------------ Current: 98.30 MB Max : 98.31 MB Buffers: 2048 Database Operations ------------------------------------------------ Reads : 9495 Writes : 4 Fetches: 5132412 Plan: ------------------------------------------------ PLAN SORT (JOIN (FACTURAS_VENTAS NATURAL, FAC_CLIENTE INDEX (IDX_FAC_CLIENTE), CLIENTES INDEX (RDB$PRIMARY85), FAC_CAJA INDEX (IDX_FAC_CAJA), CAJAS INDEX (RDB$PRIMARY77))) Table Operations: +--------------------------+-----------+-----------+-----------+-----------+-----------+ | Table Name | Index | Non-Index | Updates | Deletes | Inserts | | | reads | reads | | | | +--------------------------+-----------+-----------+-----------+-----------+-----------+ | FACTURAS_VENTAS| 0 | 1,287,862 | 0 | 0 | 0 | | FAC_CAJA| 140,898 | 0 | 0 | 0 | 0 | | FAC_CLIENTE| 140,898 | 0 | 0 | 0 | 0 | | CAJAS| 140,898 | 0 | 0 | 0 | 0 | | CLIENTES| 140,898 | 0 | 0 | 0 | 0 | +--------------------------+-----------+-----------+-----------+-----------+-----------+
otra parte interesante es que porque firebird me muestra las bases de datos diferente plan sort ejemplo: Código:
db de produccion: PLAN SORT (JOIN (FAC_CAJA NATURAL, CAJAS INDEX (RDB$PRIMARY77), FACTURAS_VENTAS INDEX (RDB$PRIMARY45), FAC_CLIENTE INDEX (IDX_FAC_CLIENTE), CLIENTES INDEX (RDB$PRIMARY85))) db de desarrollo PLAN SORT (JOIN (FACTURAS_VENTAS NATURAL, FAC_CLIENTE INDEX (IDX_FAC_CLIENTE), CLIENTES INDEX (RDB$PRIMARY85), FAC_CAJA INDEX (IDX_FAC_CAJA), CAJAS INDEX (RDB$PRIMARY77))) ¿Podrían sacarme de la duda? saludos cordial; novato_erick |
#2
|
|||
|
|||
Cordial saludo. Puedes regalarnos los scripts SQL para generar esa parte de la base de datos, con algunos datos. Esto para poder reproducir la consulta.
Personalmente al trabajar un proyecto de una base de datos, hago scripts para llenar las tablas con el estimado de información de 10 años. Allí me doy cuenta de que optimizaciones se deben hacer.
__________________
Luis Fernando Buelvas T. |
#3
|
|||
|
|||
Bueno, de lo que alcanzo a observar, la parte
hace que la operación cast tenga que hacerse en todos los registros convirtiendo el valor a fecha y luego ver si se encuentre en el rango fechaini y fechafin, por tanto hará un recorrido natural de la tabla. Si un campo es para almacenar una fecha lo mejor es que sea del tipo correspondiente, es decir, Date; ahora, si es un timestamp no es necesario hacer el cast.
__________________
Luis Fernando Buelvas T. |
#4
|
|||
|
|||
Sobre el código
Decir que de si las llaves foráneas son "not null" (es decir que debe ir un valor para esos campos) utilizar LEFT JOIN en lugar de INNER JOIN puede hacer que el plan de la consulta utilice mejor los índices. Con Firebird llevo años usando LEFT JOIN sobre INNER JOIN.
__________________
Luis Fernando Buelvas T. |
#5
|
|||
|
|||
Si envías el script de esa parte del proyecto con algunos datos personalmente te podría colaborar un poco más.
__________________
Luis Fernando Buelvas T. |
#6
|
||||
|
||||
Cita:
Y además debe verificar que ambas bases de datos son realmente iguales. |
#7
|
|||
|
|||
Cita:
Disculpa la demora.. Saludos; |
#8
|
||||
|
||||
No, eso no esta bien. Eso altera los resultados (semantica diferente!)
__________________
El malabarista. |
#9
|
|||
|
|||
Ciertamente....
__________________
"La forma de empezar es dejar de hablar y empezar a hacerlo." - Walt Disney |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Consulta update desde una consulta select | jafera | SQL | 3 | 08-05-2015 19:56:02 |
Consulta SQL basada en otra consulta anterior | jafera | SQL | 5 | 19-11-2013 01:07:37 |
Optimizando velocidad de mis páginas | lucasarts_18 | PHP | 2 | 25-09-2008 19:42:47 |
Optimizando Creación de Formularios MDI | nelostanley | OOP | 20 | 08-01-2008 03:00:36 |
Realizar una consulta sobre los registros que devuelve otra consulta | Borjaserrano | Firebird e Interbase | 12 | 01-10-2007 23:19:44 |
|