Principios de la Optimizacin de Consultas

Cuando se habla acerca de optimizar consultas en un entorno de Base de

Datos sea centralizado o distribuido ciertamente se pueden identificar
cuatro principios en los que se basa o bien cuatro pasos generales que se
llevan a cabo dentro del proceso de optimizacin de una consulta.

1- Convertir la consulta en alguna representacin interna.

El primer paso en el proceso de una consulta es convertirla en alguna
representacin interna que sea ms apropiada para la manipulacin de la
computadora, eliminando as, las consideraciones del nivel externo (tales
como los rasgos concretos de la sintaxis de un lenguaje de consulta),
preparando as el camino para los subsecuentes pasos de la optimizacin.
Se deber hacer una eleccin de manera que se represente a la consulta por
medio del lenguaje que pueda manejar el sistema de manera que los pasos
subsecuentes no se vean afectados. Por ejemplo, se tiene la consulta
"obtener los nombre de los proveedores que surten la pieza P2', es posible
representar esto en un rbol de operadores:

Esto da como resultado una expresin, dentro del lgebra relacional que se
puede manejar ms fcilmente por el sistema:

2- Convertir a forma cannica

La definicin de forma cannica es el punto central en muchas reas de las
matemticas y disciplinas relacionadas. Es posible definirla como sigue: Se
tiene un conjunto Q de objetos (Queries) y la definicin de equivalencia entre
ellos (dos queries son equivalentes, si y solo si, producen el mismo resultado),
se tiene tambin un subconjunto C de Q, el cual se llama conjunto de formas
cannicas de Q (bajo la definicin de equivalencia), si y solo si, algn objeto q
en Q es equivalente a solo un objeto c en C. El objeto c es llamado la forma
cannica de q. Todas las propiedades que se aplican a q se aplican a la forma
cannica c; As, es suficiente realizar el estudio del pequeo conjunto de
formas cannicas, y no del gran conjunto de Q.
Durante este paso, el optimizador ejecuta un nmero de transformaciones que
son "garantizadas para ser correctas', en relacin con los datos actuales y las
rutas de acceso que existen en la base de datos. El punto es que la mayora de
los lenguajes de consulta permiten que hasta la ms simple consulta pueda ser
expresada en una variedad de formas distintas. Tan solo en SQL, la consulta
de la seccin anterior tiene ocho posibles representaciones.
La obtencin de expresiones equivalentes se logra por medio de reglas de
transformacin, bien definidas y permitidas dentro del lgebra relacional.

3- Elegir el procedimiento de bajo nivel.

Habiendo convertido la representacin interna de la consulta en alguna forma
ms deseable (forma cannica), se debe decidir cmo se evaluar la consulta,
representada por su forma cannica.
En este paso se debe considerar la existencia de ndices, rutas de acceso,
distribucin de los datos almacenados, almacenamiento fsico de los registros,
etc.

La estrategia bsica es considerar la consulta como una serie de operaciones

de "bajo nivel" join, select, project, etc.), con cierta interdependencia entre ellos.
Para cada operacin de bajo nivel, se tendr un conjunto de procedimientos
predefinidos; Por ejemplo, un conjunto de procedimientos para la seleccin
sera, un procedimiento para cuando los campos estn indexados, y otro para
cuando no lo estn, pero estn almacenados fsicamente en orden, etc. Cada
procedimiento tiene asociado un costo.

4- Seleccionar el procedimiento ms econmico.

El paso final del proceso de optimizacin involucro la construccin de un
conjunto de planes de ejecucin de consultas candidatas seguido de la
eleccin del mejor (ms econmico) de estos planes.
Cada plan es construido con la implementacin de los procedimientos
necesarios para ejecutar la consulta. Ser necesario un procedimiento por cada
operacin de bajo nivel en la consulta. No es necesario construir todos los
planes posibles, basta con generar una cantidad razonable de procedimientos y
realizar combinaciones entre ellos y seleccionar el conjunto ms econmico
para la ejecucin de la consulta. La asignacin del costo a algn plan
involucrar el nmero de accesos a disco, la utilizacin del CPU, etc.
Dentro del costo de una consulta tambin deber tomar en cuenta la
transmisin de los datos dentro del sistema en el cual se lleva a cabo dicha
consulta. Es importante recordar que dentro de un sistema de bases de datos
distribuidas, la informacin se encuentra dispersa dentro de varios servidores y
es utilizada por muchos clientes, los cuales pueden estar a corta distancia de
los servidores o muy alejados de estos. Cuando una consulta es lanzada en un
sistema de bases de datos distribuidos, en ese momento es posible saber que
informacin se requiere y en que sitio se encuentra. Entonces se debe decidir
la forma en que se realizar el proceso de recoleccin de datos. Es decir, la
tabla es enviada ntegramente al sitio que lanzo la consulta o solo los registros
que cumplen con la condicin, tal vez es necesario que otro sitio realice el
proceso de recoleccin de resultados parciales y solo se reciba el resultado
final o si el sitio que lanzo la consulta, realice el proceso integro, etc.

En un sistema distribuido de bases de datos, el costo ms alto es el de la

comunicacin, por ello es necesario utilizar estrategias para reducirlo. Como se
vio en el captulo anterior (Ejemplos de consultas distribuidas), es necesario
considerar, de cierta forma, la capacidad de procesamiento de los equipos para
decidir qu equipo o equipos realizaran los procesos ms demandantes.

Recomendaciones para optimizar Consultas

Gestin y eleccin de los ndices
Los ndices son campos elegidos arbitrariamente por el constructor de la base
de datos que permiten la bsqueda a partir de dicho campo a una velocidad
notablemente superior. Sin embargo, esta ventaja se ve contrarrestada por el
hecho de ocupar mucha ms memoria (el doble ms o menos) y de requerir
para su insercin y actualizacin un tiempo de proceso superior.
Evidentemente, no podemos indexar todos los campos de una tabla extensa ya
que doblamos el tamao de la base de datos. Igualmente, tampoco sirve de
mucho el indexar todos los campos en una tabla pequea ya que las
selecciones pueden efectuarse rpidamente de todos modos.
Un caso en el que los ndices pueden resultar muy tiles es cuando realizamos
peticiones simultneas sobre varias tablas. En este caso, el proceso de
seleccin puede acelerarse sensiblemente si indexamos los campos que sirven
de nexo entre las dos tablas.
Los ndices pueden resultar contraproducentes si los introducimos sobre
campos triviales a partir de los cuales no se realiza ningn tipo de peticin ya
que, adems del problema de memoria ya mencionado, estamos ralentizando
otras tareas de la base de datos como son la edicin, insercin y borrado. Es
por ello que vale la pena pensrselo dos veces antes de indexar un campo que
no sirve de criterio para bsquedas o que es usado con muy poca frecuencia
por razones de mantenimiento.

Campos a Seleccionar
Seleccionar exclusivamente aquellos que se necesiten. No utilizar nunca
SELECT * por qu el gestor debe leer primero la estructura de la tabla antes de
ejecutar la sentencia
Si se utilizan varias tablas en la consulta especificar siempre a que tabla
pertenece cada campo, le ahorra al gestor el tiempo de localizar a que tabla
pertenece el campo. En lugar de SELECT Nombre, Factura FROM Clientes,
Facturacion

WHERE

Clientes.Nombre,

IdCliente

Facturacion.Factura

IdClienteFacturado,
WHERE

usa:

SELECT

Clientes.IdCliente

Facturacion.IdClienteFacturado.

Uso de JOIN vs Selects Anidados

Aparte de que son menos mantenibles y legibles, los selects anidados tienen
un alto impacto en cuanto a recursos usados. Por regla general adems, es
recomendable no usar SELECTs anidados y usar nicamente JOINs ya que el
rendimiento es casi siempre mejor. Recuerdemos que, por regla general,
podemos convertir un SELECT anidado en un JOIN fcilmente:
SELECT usuario
FROM usuarios
WHERE id IN (
SELECT id
FROM datos_usuario
WHERE departamento = 1
)

Ahora con JOINs

SELECT usuarios.usuario
FROM usuarios
INNER JOIN datos_usuario ON usuarios.id = datos_usuario.id
WHERE datos_usuario.departamento = 1;

Uso de cursores
Si la consulta utiliza cursores determina antes si se puede escribir la consulta
con un tipo de cursor ms eficaz (como uno de avance rpido) o con una nica
consulta. Las consultas nicas mejoran las operaciones de cursor.

Dado que un conjunto de instrucciones de cursor suele constituir una operacin

de bucle externo, en la que cada fila del bucle se procesa una vez con una
instruccin interna, se puede contemplar la posibilidad de utilizar en su lugar
una instruccin GROUP BY o CASE. Quiz incluso una subconsulta.

Uso de alias
No utilizar varios alias para una sola tabla en la misma consulta para simular la
interseccin de ndices. Ya no es necesario debido a que SQL Server tiene en
cuenta automticamente la interseccin de ndices y puede utilizar varios en la
misma tabla de la consulta.

Uso de la parametrizacin
Utilizar la parametrizacin de consultas para permitir la reutilizacin de los
planes de ejecucin de consulta almacenados en la memoria cach. Si un
conjunto de consultas tiene el mismo hash de consulta y hash de plan de
consulta, podra mejorar el rendimiento creando una consulta parametrizada.
Llamar a una consulta con parmetros en lugar de a varias consultas con
valores literales permite reutilizar el plan de ejecucin de consulta almacenado
en la memoria cach.

Uso de Exists
Cuando queramos hacer una sub-consulta en una base de datos utilizando la
sentencia NOT IN, analicemos si podemos cambiar nuestro queries con el uso
de la sentencia Exists que es mucho ms eficiente que la anterior. O en todo
caso, utilizar IN en vez de NOT IN, ya que esto hace un escaneo completo en
la tabla descartando opciones a omitir.

Uso de Distinct
Utilizar distinct para excluir datos duplicados es muy usado por los
programadores para evitar errores de diseo de base de datos y as esconder
algunos duplicidad de informacin, pero esto es un grave error. Es una de las
sentencias que ms necesita hacer I/O en el disco y forzar bastante el
procesador. Por tal motivo, si no es necesario evitemos utilizarla.

Uso de Tops
Cuando se quiere traer un grupo de registros es mejor utilizar la sentencia Top
y no Rowcount, ya que esta ltima presenta inconvenientes con listas no
ordenadas. En cambio, si la lista es ordenada es ms eficiente que la sentencia
Top.

Verificar si existe un registro

Muchos programadores utilizan el count(*) para ver si un registro existe en la
base de datos, pero una forma ms eficiente de hacerlo es con Exists. Cuando
ste encuentra un registro detiene la bsqueda del mismo.

Uso de ORDER BY
Usar ORDER BY en las QUERIES que se lancen slo si es absolutamente
indispensable. Es decir, que si es posible realizar la ordenacin en el lado del
cliente siempre ser mejor que realizarla desde el lado del servidor SQL Server.
En caso de que sea absolutamente necesario realizar la ordenacin en el lado
del servidor SQL Server deberemos atender a las siguientes recomendaciones:

Mantener el nmero de filas a ordenar al mnimo

Mantener el nmero de columnas a ordenar al mnimo
Mantener el ancho (tamao fsico) de las columnas a ordenar al mnimo
Ordenar columnas con datos numricos (NO tipos de datos carcter)

 Cuando usemos cualquier mecanismo de ordenacin en Transact SQL,

debemos tener en mente todas estas recomendaciones para la mejora
del rendimiento.
Si se ha de ordenar por una columna a menudo, debemos considerar el
realizar un Clustered Index sobre esa columna para la mejora del
rendimiento.

Bibliografa

Optimizacin de consultas. Libro: Fundamentos de Bases de Datos

Silberschatz et al. 5ed. Dr. Vctor J. Sosa.
www.tamps.cinvestav.mx/~vjsosa/clases/bd/OptimizacionConsultas.pdf
Procesamiento y optimizacin de consultas - Marta Zorrilla Universidad de
Cantabria.
personales.unican.es/zorrillm/DiseoAdmonBD/temas/08-consultas%20%20optimizacion.pdf
Base de datos distribuidos optimizacin de las estrategias de acceso.
Jos Mario Martnez Castro. Chilpancingo, Gro. Febrero del 2007.
jmmc.uagro.mx/bdd/ApuntesBDDsU3.pdf
Procesamiento de consultas Distribuidas.
http://es.scribd.com/doc/57809235/Capitulo-4-Procesamiento-de-ConsultasDistribuidas.
Base de datos distribuidos.
es.scribd.com/doc/80918426/Bases-de-Datos-Distribuidas.
Procesamiento y optimizacin de consultas.
ocw.uc3m.es/ingenieria-informatica/diseno-y-administracion-de-bases-dedatos/teoria/Tema4_5(Administracion_OptimizacionConsultas).pdf
Optimizacin.
www.unirioja.es/cu/arjaime/Temas/07.Optimizacion.pdf
Optimizar Consultas SQL.
http://www.desarrolloweb.com/articulos/2230.php
Consejos para crear y optimizar consultas en SQL.
www.awerty.net/telemantenimiento/realizar-consultas-en-sql/
Recomendaciones para optimizar consultas.
http://technet.microsoft.com/es-es/library/ms188722(v=sql.105).aspx
Optimizacin de las estrategias de acceso.
http://luisantoniosr.webcindario.com/BDD/bdd_unidad3.html
Optimizador de consultas.
es.wikipedia.org/wiki/Optimizador_de_consultas