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.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#7
|
||||
|
||||
No, eso no esta bien. Eso altera los resultados (semantica diferente!)
__________________
El malabarista. |
#8
|
|||
|
|||
Ciertamente....
__________________
"La forma de empezar es dejar de hablar y empezar a hacerlo." - Walt Disney |
#9
|
||||
|
||||
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#10
|
|||
|
|||
Ya hicieron la prueba ? Si la llave foránea es "not null" funciona como un inner join. Sigo trabajando con bases de datos Firebird 1.5 y el preprocesador (el que define el plan de la consulta) no selecciona algunos índices como uno esperaría. Mis consultas funcionan como espero que funcionen. En Firebird 3 he tratado de usar inner join pero si no toma el índice que espero paso a usar left join siempre y cuando la llave foránea tenga valor (definiéndola not null). Lo que pasa es que trabajo casi exclusivamente con Interbase y luego Firebird desde el año 1998. Firebird 1.5 es suficiente para todo, pero ahora Windows 10 cada vez que hace una actualización importante desinstala el motor de base de datos por el defecto que tiene el instalador de Firebird 1.5 que el Applet que se adiciona al panel de control hace que éste cuando se abre se cierra inmediatamente. Para instalar Firebird 1.5 toca cambia el nombre del instalador pero de tanto en tanto Windows 10 lo desinstala. Estoy moviéndome a Firebird 3 pero los componentes IBX no van bien con este motor por lo que adquirí UniDac y estamos pasando de VCL a uniGui y de IBX a uniDac.
__________________
Luis Fernando Buelvas T. |
#11
|
||||
|
||||
¿En qué no van bien?
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#12
|
||||
|
||||
Cita:
Cita:
Ni te imaginas lo mucho que ha avanzado el tema de los RDBMS estos años. Y esos avances están siendo aplicados constantemente. Los RDBMs son MUY competitivos entre ellos. --- No siempre elegir un indice es lo mejor. Una de las tareas del query planer es determinar la manera menos costosa de ejecutar la consulta. Si este determina que usar el indice trae un mayor costo, lo DESCARTA. Ahora, es posible que este se "equivoque?". Si. Y es posible que DIO LA CASUALIDAD que en la version vieja no cometa el error y en la nueva sí? Claro. Y eso significa que es mejor usar la vieja? NOOOOOOOO. Porque es MUY probable que la nueva manifieste un ERROR de logica y/o diseño que la vieja, por casualidad NO VE. Asi que:
Pero en toda mi vida, usando como 8 rdbms diferentes solo he tenido que forzar a Mysql (que en versiones antes tenia el query planer mas imbecil del mundo. Todos los join era nested loops, que asco!) y aun asi, termine reescribiendo el query mejor. Siempre sigue estos pasos:
__________________
El malabarista. |
#13
|
|||
|
|||
Cita:
Disculpa la demora.. Saludos; |
#14
|
|||
|
|||
Ciertamente Si...
egostar, Casimiro, mamcx es un gran privilegio que lean mi post ayudadome como siempre.. Bendiciones Totales.... Por cierto uso el inner join porque se que cada fila de la tabla A exista una fila en la tabla B. bueno en teoría. Provaré la sugerencia de lbuelvas del uso del CAST.. Saludos y les informo |
#15
|
|||
|
|||
Descartado funcion CAST en Campo TimesTamp
La verdad como había mostrado dos resultado de respuesta a mi consulta en Base de datos de Desarrollo y la misma en producción obteniendo resultado lento en la de producción mas no en la de Desarrollo descarto totalmente el campo fecha como causa sugerido por nuestro compañero lbuelvas. aun me encuentro en pruebas. Agregué el script solicitado por ustedes. Saludos; |
#16
|
||||
|
||||
Otra cosa a tener en cuenta y que es más importante de lo que puedas pensar, usa dominios.
De siempre, en todos los campos, usar dominios.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#17
|
|||
|
|||
Hola, me alegra que se haya dado la discusión. Gracias por las recomendaciones sobre el uso de Inner Join, voy a revisar una parte de un proyecto actual donde en las pruebas generé 1.00.000 de registros en dos tablas que están relacionadas 1:M.
Colocaré los resultados para continuar con el tema que se me hace interesante, por eso respondí tan pronto el compañero escribió su inquietud. Revisaré mañana el script y espero que mis comentarios sean de ayuda. Un abrazo para todos.
__________________
Luis Fernando Buelvas T. |
#18
|
|||
|
|||
Cita:
Interesante Casimiro Notevi nunca me pareció relevante usar los dominios en fin será porque en la teoría normalmente se lo dejo al motor de base de datos En este caso según usar dominion en Firebird no son los tipos de datos estándar sino los creados por el programador la para cubrir sus propias necesidades. al principio mi necesidad fue simplemente usar tipos de Datos que normalmente están en el motor. En fin ahora quedé con la duda 'Perdonen mi ignorancia' del uso del dominio a la hora de realizar consulta anidadas de diferentes tablas. Saludos a todos; novato_erick |
#19
|
|||
|
|||
Cita:
Saludos; |
#20
|
||||
|
||||
Puedes ponerlo en un link de dropbox o similar.
__________________
El malabarista. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Consulta update desde una consulta select | jafera | SQL | 3 | 08-05-2015 20:56:02 |
Consulta SQL basada en otra consulta anterior | jafera | SQL | 5 | 19-11-2013 02:07:37 |
Optimizando velocidad de mis páginas | lucasarts_18 | PHP | 2 | 25-09-2008 20:42:47 |
Optimizando Creación de Formularios MDI | nelostanley | OOP | 20 | 08-01-2008 04:00:36 |
Realizar una consulta sobre los registros que devuelve otra consulta | Borjaserrano | Firebird e Interbase | 12 | 02-10-2007 00:19:44 |
|