En una base de datos
no puedes ver las sentencias en tiempo de ejecución, lo que puedes visualizar es, con algunas herramientas, el plan de consultas que el parser genera. No puedes verlas en ejecución porque, entre otras cosas,
el SQL no es un lenguaje de programación sino un lenguaje de consultas que opera contra los recursos de un DBMS, y es éste el que realiza la tarea, según un gran conjunto de algoritmos preestablecidos.
El núcleo de MySQL está programado en C por lo que, te imaginarás, no se puede ejecutar sin compilar, y con ello pierdes completamente el rastro del proceso que se ejecuta.
El plan de ejecución, por otra parte, te lo muestran ciertas herramientas de los BDMS como es el caso del Analizador de Consultas de MSSQL Server. En el caso de MySQL, éste tiene una sentencia (
EXPLAIN) que te permite ver cómo realizará la consulta, cuántos registros se afectan en cada paso, qué indices usa, cuáles campos pueden ser claves candidatas, qué filtrados usó, cómo generó la combinatoria, etc.
En ese contexto, te imaginarás que la optimización de consultas no es algo que acabe con la escritura de la sentencia: Esa es sólo una parte del problema.
La optimización de consulta tiene relación con:
- La optimización del diseño de tablas.
- La elección de los tipos de columna correctos.
- Las restricciones, chequeos y validaciones que se hacen.
- Las claves usadas.
- Los índices definidos, sus claves y sus tipos.
- El hardware usado.
- Las versiones de server de DBMS usado.
- El nivel de enlace de red que esté operando.
- La configuración de parámetros del servidor.
- Otros (muchos) factores.
Todo esto, antes de definir cómo se hace la consulta, ya está afectando la velocidad del resultado. Y Sólo al llegar a ese nivel empieza a aparecer el SQL propiamente dicho:
- Los datos que se desean recuperar (nunca más de los necesarios).
- La elección de los índices apropiados al resultado deseado (no todos los índices se usan ni se necesitan en todas las consultas).
- El nivel de selectividad de los datos a cruzar (los datos que se usan de relación afectan la reducción de registros a procesar).
- La secuencia de cruces que se planea (el orden afecta la selectividad).
- El método usado para el cruce de datos (ciertas combinaciones devuelven cantidades de datos inmensos en un caso y en otro no).
...Y entre todas estas consideraciones surge un detalle que nunca hay que perder de vista:
La misma consulta, con los mismos datos en las mismas tablas y las mismas cantidades, puede dar resultados distintos de tiempo en dos ejecuciones en momentos diferentes, sin que eso signifique que haya un error en ninguna parte.
Simplemente es que los DBMS trabajan también con herramientas estadísticas internas que les ayudan a cambiar el plan de ejecución si ciertos caminos se prueban ineficientes o más lentos que otros en determinadas circunstancias.
El tema, finalmente, es que para la optimización de consultas existen algunas reglas, pero no leyes; es decir, la optimización de las consultas se realiza sobre una base en específico siguiendo ciertas reglas generales, pero al final, depende de las tablas reales involucradas y las consultas específicas de ese caso.
Para poder ayudarte eficientemente nos debes dar una idea clara de la estructura y de los datos involucrados, así como qué cosas exactamente quieres lograr.
Sobre el tema hay mucho en internet:
http://hackmysql.com/documents Mysql Query Optimization Zurich2007 MySQL Query Optimization MySQL Performance Blog 
Respuesta: Preguntas sobre Optimizacion 
