Cómo optimizar una consulta SQL

¿Para qué optimizamos? Para obtener de manera más rápida y precisa la información, más eficiente. Hay que tomar en cuenta que el bajo rendimiento en el tiempo de respuesta se deben a factores como: el hardware, el software, el SGBD, el diseño, índices mala formulación de las consultas.
A continuación se siguen algunos tips, no son todos los que hay pero es algo para tomar en cuenta.

Diseño de 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.

Í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:

Claves Primarias Claves Foráneas
Campos por los cuales se realizaran búsquedas
Campos por los cuales se va a ordenar
**Siempre conviene indexar tablas con gran cantidad de registros y que van a ser consultadas intensamente.

Formulación de las consultas
**En la medida de lo posible hay que evitar que las sentencias SQL estén embebidas dentro del código de la aplicación. Es mucho más eficaz usar vistas o procedimientos almacenados por que el gestor los guarda compilados. Si se trata de una sentencia embebida el gestor debe compilarla antes de ejecutarla.

**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. (Con respecto a esto, aún no sé. Eso se suele decir, sin embargo un docente de mi universidad me dijo que es indiferente.)
**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.

**Cuando se utilizan varias tablas dentro de la consulta hay que tener cuidado con el orden empleado en la cláusula FROM. Si deseamos saber cuantos alumnos se matricularon en el año 1996 y escribimos: FROM Alumnos, Matriculas WHERE Alumno.IdAlumno = Matriculas.IdAlumno AND Matriculas.Año = 1996 el gestor recorrerá todos los alumnos para buscar sus matriculas y devolver las correspondientes. Si escribimos FROM Matriculas, Alumnos WHERE Matriculas.Año = 1996 AND Matriculas.IdAlumno = Alumnos.IdAlumnos, el gestor filtra las matrículas y después selecciona los alumnos, de esta forma tiene que recorrer menos registros