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 Código:
Query Performance
otra parte interesante es que porque firebird me muestra las bases de datos diferente plan sort ejemplo: Código:
db de produccion: ¿Podrían sacarme de la duda? saludos cordial; novato_erick |
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. |
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. |
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. |
Si envías el script de esa parte del proyecto con algunos datos personalmente te podría colaborar un poco más.
|
Cita:
Y además debe verificar que ambas bases de datos son realmente iguales. |
Cita:
|
Cita:
|
Cita:
|
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.
|
Cita:
|
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:
|
Cita:
Disculpa la demora.. Saludos; |
Cita:
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 |
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; |
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.
|
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. |
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 |
Cita:
Saludos; |
Puedes ponerlo en un link de dropbox o similar.
|
Hola, puedes subirlo a mi servidor
http://45.77.164.42/HFS_Publica/ Se pueden subir archivos y bajarlos, pero no borrarlos, me avisas cuando lo puedo borrar. |
Compañeros dejo el enlace para descarga:
https://drive.google.com/open?id=1uv...1_ATD9mOXaQ-1I Saludos; novato_erick |
Cita:
Deje en enlace y tambien lo subi a tu servidor. Saludos y muchas gracias por tu colaboración; novato_erick. pd: el que administre este foro no estaría interesado que colaboremos en un servidor para este tipo de situaciones de subir info a los miembros? |
Estuve revisando tus metadatos y encuentro que no tienes llaves foráneas, entonces suspendí la revisión. Regálanos por favor una base de datos donde recortes lo que no estés interesado en que nosotros veamos y una porción de registros. Luego de recortar lo que es dispensable, haces Backup/Rrestore para disminuir el tamaño del archivo, lo comprimes y lo envías.
Lo otro que podemos hacer es hacer una sesión remota, yo tengo licencia de Ammyy y hablamos por Telegram o Whatsapp porque veo que tu base de datos tiene muchos registros. Como estás en Panamá tenemos el mismo horario, yo estuve por allá hace unos 15 días en un Crucero por el Caribe que nos ganamos mi esposa y yo, estuvimos medio día por allá, es muy bonito. |
Cita:
En referencia a las Llaves foráneas cuando tomé el proyecto también noté lo mismo en la Tabla FACTURAS_VENTAS con sus tablas hijas o dependiente en fin a pesar de no poseer dicha llave foraneas no ha perdido integridad en cuanto a las transacciones a cada tabla. Casi son dos millones de registros. en Fin realizé una recreación de los indixes de todas las tablas leyendo un poco este link https://firebird21.wordpress.com/tag/reindex/ la cual al ejecutarlo se corrigió el problema de consulta también cree un nuevo campo la cual guarda solamente el tipo de dato de FECHA sin la hora para evitar usar la función cast de Firebird en la consulta y tenias razón si mejoró notablemente. También el consejo de: Cita:
Antes de quitar la función DESCENDING Código:
Query Performance Quitando la función DESCENDING Código:
Query Performance - recrear los indice ya que en la db habia 160 mil registros de diferencia entre mi tabla de desarrollo y la tabla de producción sin indexar eso también jugó un papel importante así que significativamente la recreación de los indice debe de realizarse cada cierto tiempo en fin no encontré por el momento alguna sugerencia en ese tema. - usar la función Cast de firebird para convertir la fecha si afecta algo en el rendimiento de la consulta Mejor utilizar el tipo de Dato correspondiente a sólo Fecha - El uso de las funciones hay que saber cuando hay que usarla en caso de consultas de búsquedas de mucha cantidad de registros. Esto juega un papel importante (Tener bien claro cada consulta). Doy solucionado dejaré terminado este tema. Saludos y Bendiciones a todos; novato_erick |
Cita:
|
Cita:
^\||/ Gracias. Saludos; novato_erick |
La franja horaria es GMT +2. Ahora son las 00:09:36. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi