Optimización de consultas SQL

Uno de los temas más importantes en el desarrollo de cubos y reportes es el tiempo de procesamiento y ejecución. Cada día se necesita procesar mayor cantidad de datos y obtener de manera más rápida y precisa la información. Muchos de los problemas de rendimiento se deben entre otras cosas  al hardware, al software, al motor de base de datos y por sobre todo al diseño, índices y mala formulación de consultas SQL. En este apartado nos centraremos en estos últimos en donde siguiendo algunas recomendaciones veremos que se puede  mejorar el tiempo de respuesta de nuestro motor de BD significativamente.

A la hora de diseñar la base de datos

·         Las tablas normalizadas permiten reducir al mínimo el espacio ocupado por nuestra base y permiten asegurar la consistencia de la información al mismo tiempo que son muy rápidas para la realización de transacciones, pero generan un mayor tiempo de demora a la hora de consultarlas ya  que se deben realizar generalmente la unión de varias tablas, por lo que en caso de necesidad de altas velocidades de respuesta con grandes volúmenes de datos un modelo desnormalizado es más que conveniente teniendo en cuenta todas las implicancias del caso.

·         Ajustar al máximo el tamaño de los campos ayuda a no desperdiciar espacio.

·         Eliminar todo campo que no sea de utilidad ya que por más que  no contenga datos genera retrasos.

Que pasa con los índices

·         Los índices son campos que permiten la búsqueda a partir de dicho campo a una velocidad notablemente superior. Sin embargo cuentan con la desventaja que hacen más lenta la actualización, carga y eliminación de los registros ya que por cada modificación en la tabla se deberá modificar también el índice, además se debe tener en cuenta el hecho de que los índices también ocupan espacio en disco. Es por esto que no  es factible indexar todos los campos de la base y se hace necesario seleccionarlos cuidadosamente. Cabe destacar que por defecto las tablas no contienen índices por lo que la introducción de estos puede llegar a producir mejoras de más del 100% en algunos casos.

Los campos que se recomiendan indexar son:

o   Claves Primarias

o   Claves Foráneas

o   Campos por los cuales se realizaran búsquedas

o   Campos por los cuales se va a ordenar

Siempre conviene indexar tablas con gran cantidad de registros y que van a ser consultadas intensamente.

Donde escribir las sentencias

·         Siempre es preferible utilizar consultas almacenadas dentro del motor de base de datos y no dentro de la aplicación, una consulta almacenada en un procedimiento almacenado por ejem , se ejecuta mucho mas rápido y directamente sobre el motor que cualquier consulta externa.

·         Muchas de las aplicaciones sobre todo de reporting permiten unir y realizar los joins y consultas directamente en la herramienta produciendo una baja de performance realmente considerable. Lo correcto y más eficiente seria generar la consulta en un sp con todos los joins y guardar el resultado en una tabla temporal, de donde posteriormente el reporte solo deberá mostrar los datos sin necesidad de trabajarlos primero. Dependiendo los joins que intervengan y los registros involucrados se pude mejorar drásticamente la performance , han habido casos en que reportes  que duraban 3 min en generarse pasaron a 30 seg., usando esta técnica.

Acerca de la formulación de la consultas:

A la hora de ejecutar una consulta SQL la forma en que esta es expresada afecta directamente al motor de BD, pequeños cambios pueden significar la ganancia de muchos segundos o minutos que el usuario debe esperar al momento de ejecutar  la consulta. Algunas recomendaciones son:

·         No utilizar SELECT * por que el motor  debe leer primero la estructura de la tabla antes de ejecutar la sentencia.

·         Seleccionar solo aquellos campos que se necesiten, cada campo extra genera tiempo extra.

·         Utilizar Inner Join , left join , right join, para unir las tablas en lugar del where, esto permite que a medida que se declaran las tablas se vallan uniendo mientras que si utilizamos el where el motor genera primero el producto cartesiano de todos los registros de las tablas para luego filtrar las correctas, un trabajo definitivamente lento.

·         Especificar el alias de la tabla delante de cada campo definido en el select, esto le ahorra tiempo al motor de tener que buscar a que tabla pertenece el campo especificado.

·         Evitar el uso de Cast. Y formulas dentro de las consultas, cada formula y casteo retrasan el motor considerablemente.

El orden de ubicación las tablas en el from deberían ir en lo preferible de menor a mayor según el número de registros , de esta manera reducimos la cantidad de revisiones de registros que realiza el motor al unir las tablas a medida que se agregan.

About these ads
Explore posts in the same categories: Técnico

10 comentarios en “Optimización de consultas SQL”

  1. yanislav Says:

    buenas recomendaciones, a veces se olvidan
    gracias por la informacion
    atte.
    yanislav

  2. malu Says:

    Muy interesante el artículo, sería útil otro donde se profundice en las recomentaciones indicadas.

  3. fernando Says:

    Me interesaria saber o que me ayuden:

    Digamos que dada una lista de productos quisiera obtener un listado de clientes que hallan comprado todo esos productos. (cada factura es una compra). El problema que tengo es que tengo miles de productos, y millones de facturas y miles de clientes.
    Cual seria una consulta aconsejable que tenga buen rendimiento antes esta situacion

    Las tablas
    productos(id,nombre) simplemente un nombre y un codigo
    facturas(producto_id,cliente_id) un producto y un cliente o sea una compra
    clientes(id,nombre) codigo de cliente y un nombre de cliente

  4. stiven Says:

    super buenas las recomendaciones…. gracias

  5. daniel Says:

    Excelentes tips… gracias por compartir tus conocimientos,, solo como sugerencia sería incluir algunos ejemplos,., .

    Me ha servido mucho lo que nos compartes, Gracias!!!

  6. Usuario Says:

    Muy buenas sugerencias, sobre lo de las consultas dentro de stored procedures es muy cierto lo que dices, pues por experiencia propia me encuentro revisando un sistema “terminado” el cual tiene consultas elaboradas desde el programa, y ya te imaginaras como demora.

    En fin, ojala mas programadores usen las buenas practicas.

  7. david Says:

    Buenas,

    Muy útil el artículo.

    Sobre la ubicación de las tablas en el FROM, es preferible ubicarlas según el número de registros que contienen las tablas o sobre el número de registros que esperamos que nos devuelva?

  8. Braulio Says:

    Hey brother, Thanks for these recomendations. It´s very usuful.

  9. master Says:

    buenas recomendaciones pero como ejecuto sp con c#.net 2008?

  10. master Says:

    estoy utilizando oracle 10g


Deja un comentario

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


Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

A %d blogueros les gusta esto: