Optimización de Consultas SQL parte II

Continuando con el post iniciado por mi compañero Lucas Forchino enunciaré algunos tips a tener en cuenta a la hora de generar la sentencia SQL de manera que el motor de BD la ejecute más eficientemente.

Comenzaremos con tres puntos en particular a tener en cuenta y entender porqué mejoran tanto nuestras sentencias SQL.

  • EMPAREJAMIENTOS EN WHERE VS. EMPAREJAMIENTOS EN EL FROM
    • ORDEN DE PROCESAMIENTO DE UNA CONSULTA MULTITABLA
  • COMPOSICIONES EXTERNAS (EN EL WHERE Y EN EL FROM)
  • QUERY PERFORMANCE

COMPOSICIONES EN EL WHERE VS. COMPOSICIONES EN EL FROM

Debido al orden de procesamiento de una consulta multitabla el motor de BD se ve beneficiado si las composiciones son realizadas en el FROM a través de INNER JOIN o alguna de sus variantes (LEFT OUTER JOIN, RIGHT OUTER JOIN). Esto se debe a que el motor al procesar una consulta SQL lo hace en este orden:

  • Realiza el producto cartesiano de las tablas en el FROM
  • Si existe cláusula WHERE aplica la condición de búsqueda
  • Para las filas restantes calcula el valor de cada elemento en la lista del SELECT
  • Si existe un SELECT DISTINCT elimina las filas duplicadas
  • Si existe un ORDER BY ordena el resultado

Al ser el primer paso el producto cartesiano de las tablas que se encuentran listadas en el FROM, dependiendo del número de columnas de cada tabla y la cantidad de registros en cada una de ellas, se genera un resultado que puede llevarle demasiado tiempo al motor de BD, y luego tiene que aplicar la condición existente en la cláusula WHERE para reducir el número de registros resultante del producto cartesiano. Si nosotros realizamos la composición directamente en el FROM evitamos utilizar la cláusula WHERE para dicho propósito haciendo mucho más eficiente la consulta, ya que al momento de realizar el producto cartesiano estamos diciéndole al motor qué registros queremos de ese producto. La sintaxis sería la siguiente:

                SELECT F.numFactura,C. CliNom, F.Monto

                FROM Factura F INNER JOIN Cliente C ON F.codcli=C.codcli

Como vemos no necesitamos la cláusula WHERE para realizar el emparejamiento de las tablas, si sería necesaria la cláusula WHERE  si quisiéramos filtrar los resultados de dicha consulta por fecha o monto por ejemplo. Si nuestra composición entre tablas requiere más de un campo y más de dos tablas la sintaxis sería la siguiente:

SELECT F.numFactura, C.cliNom, F.Monto, V.venNom

FROM Factura F INNER JOIN Cliente C ON F.tipoDoc=C.tipoDoc     AND F.numDoc=C.numDoc INNER JOIN Vendedor ON F.codVen=V.codVen

COMPOSICIONES EXTERNAS

Al realizar composiciones internas o INNER JOIN entre dos tablas, los registros que no se correspondan en ambas tablas son eliminados de la lista de resultados, si yo no deseo que se eliminen los registros de una o ambas tablas aunque queden desemparejados debo realizar composiciones externas. Por ejemplo:

join_00011.jpg

Existen registros en la tabla TMARCAS que no se encuentran en la tabla TCOCHES, si yo realizo una composición interna esas marcas no formarían parte de mi conjunto de resultados. Al realizar una composición externa podría recuperar todo el conjunto de resultados, las composiciones externas dependen del orden en el que se listen las tablas:

SELECT TC.Coche, TM.marca

 FROM TCOCHES TC RIGHT OUTER JOIN TMARCAS TM ON TC.marca=TM.codigo

QUERY PERFORMANCE

Buenas prácticas para mejorar nuestras consultas SQL

  • Realizar las composiciones en el FROM
  • Tener en cuenta el orden en el que enunciamos las tablas en el FROM
  • Uso de funciones de T-SQL
  • Evitar el uso de SELECT *
  • Evitar el SELECT DISTINCT y el ORDER BY

Estas fueron unas breves recomendaciones a tener en cuenta a la hora de generar nuestras sentencias SQL, más adelante seguiremos con este tema, por ejemplo el uso de subconsultas, consultas en el FROM, uso de IF y CASE para condiciones, etc. las cuales son fundamentales a la hora de realizar nuestros procesos ETL.

Explore posts in the same categories: Técnico

14 comentarios en “Optimización de Consultas SQL parte II”

  1. Roberto Says:

    Muy bueno el articulo.
    Como hiciera para conseguir la parte I y el resto de articulos que han escrito.

    Gracias.
    Roberto
    Costa Rica

  2. jernet Says:

    ante todo me gusto tu articulo….bien conpacto y directo….queira hacer un pequeño aporte que no e visto en los articulos de este tipo…como informatico de un banco….hago mension es un caso especifico…y es la utilizacion de funciones en los campos para los join y los where…

    ejemplo de eso es la funcion convert()…de ser posible no ocupar tales funciones..ya que esto provoca que se pierda el index vinculado a ese campo…existen alternativas
    para modificar el contenido como el rtrim y ltrim

    bueno
    atte jernet
    chile

  3. Hugo C.R. Says:

    Este articulo esta muy bueno, me aclaro algudas dudas que tenia.
    Gracias.


  4. Hola, creo que sería muy interesante que indicases en qué sistemas gestores de bases de datos obtienes esa mejora de rendimiento por el uso de joins en el from en vez de en el where.

    Concretamente en SQL Server, en ambos casos el plan de ejecución es idéntico, por tanto a nivel de performance, no es ni mejor ni peor, es exactamente igual. Aunque personalmente veo más claro el uso en el from, pero sólo a nivel de ver la sintaxis más clara, el rendimiento es el mismo.

  5. LhaN Says:

    Buenas, espero que puedas responder una duda que tengo. Estoy interesado en realizar un proyecto de un juego web. Pero soy conciente que no se puede tirar uno a la pileta sin antes fijarse si tiene agua y cuanta…
    Los juegos por definicion son sumamente interactivos, llenos de actualizacion y comparaciones de datos, y en particular los juegos web (PBBG) ademas tiene la particularidad de ser tan accesibles que pueden tener miles de jugadores en el mismo momento. Por lo que he llegado a saber, el mejor sistema para implementar en los PBBG es el on demand, el cual es un problema en las horas pico, segun dicen. Pero no tengo idea como repercuten las consultas en el servidor. Asi de momento si tener mucha idea del tema se me plantean dos posibles dudas.

    La primera es… que es mas conveniente? tener una tabla con todos los campos necesarios? o tener dos tablas, una de ellas con dos o tres campos importantes.
    Para explicarme mejor, la idea de esta consulta es tener un campo de “ultima actualizacion”. Si la ultima actualizacion en una variable del cliente es anterior a la del campo en el servidor, entonces realizar una segunda consulta pidiendo los datos que se necesitan.

    La segunda duda es sobre la carga que tiene el servidor frente a ciertas consultas, cual seria el orden de menor carga a mayor carga (o si son iguales) estos 4 casos:
    1 realizar una consulta que pida UN campo
    2 realizar una consulta que pida VARIOS campos
    3 realizar una consulta que actualice UN campo
    4 realizar una consulta que actualice VARIOS campos

    A todo esto, la idea es trabajar con PHP-MySQL y Ajax, seguramente en un servidor gratuito, al menos en principio, hasta que se sature, pero si logro hacer algo bien optimizado sirve tanto para el gratuito como para uno pago.

    Por ultimo, si tienes algun consejo o idea de la cual yo este posiblemente desinformado te lo agradeceria.

    Saludos.

  6. eva Says:

    Me ha parecido muy interesante.
    Gracias por el articulo


  7. Enter your query with performance issues, information about tables and shortly you will receive recommendations for possible optimization.

    De momento es gratis.


  8. Muy bueno el artículo.

    La gente confunde en OUTER JOIN con el INNER JOIN.

    http://www.sendyourquery.com

    Enter your query with performance issues, information about tables and shortly you will receive recommendations for possible optimization.

  9. Cesar Villamil Says:

    Muy buenos sus articulos, los felicito, bastantes útiles

  10. Josue Says:

    Muy buen articulo, son estas cosas de buenas prácticas que alivian mucho el trabajo a los usuarios finales. Es la idea.

    Les saluda,

    Golveron
    josbolivar@gmail.com
    Santiago – Chile

  11. SQL User Says:

    Hola.

    Muy buenos los artículos.

    Hay una página web para la optimización de querys con problemas de rendimiento:

    http://www.sendyourquery.com

    Podéis enviar querys y recibiréis recomendaciones para su optimización.

    Un saludo.

  12. dd@hotmail.com Says:

    buen aporte ACM1PT por eso


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s


A %d blogueros les gusta esto: