Hola.
El hecho de unir los dos procedimientos en uno solo, te va a proporcionar un aumento mínimo del rendimiento.
Yo no lo haría, sobretodo cuando está claro que tienes un problema de falta de índices.(Saltarse el procedimiento almacenado, solo valdria la pena si quieres pasar de un rendimiento de, pongamos 1.5 segunos a 1.0 segundos, pero no es el caso).
Tienes que estudiar el
plan de ejecución de cada una de las consultas involucradas. Te va a indicar el índice que se utiliza para cada tabla y unión involucrada en la consulta. Lo primero que tienes que buscar es tablas donde te muestre
NATURAL, aquí te está indicando que esa tabla no se optimiza con ningún índice. (En caso de que todas las tablas utilizen un índice, entonces tendrás que buscar que índice es de poca ayuda en la consulta, y sustituirlo por un índice compuesto de varios campos).
Además puedes utilizar un depurador de procedimientos almacenados. Ejecutando línea a línea el procedimiento almacenado, vas a ver en que línea se pierde el rendimiento.
Utiliza SQL'92 y no SQL'89 (creo). Estás creando un producto cartesiano :
Código:
select distinct
renopla2.NUMALU, renopla2.nombre, renopla2.TELFALU, renopla2.nomcli,
renopla2.fecfincurso, grupos.alias
from renopla2 EXTE, grupos , comen
where (( select count (*) from renopla2 inte
Where inte.numalu=exte.numalu)=1 )
and ((renopla2.numalu=comen.numalu) and (comen.tipo=97) and (comen.alias=grupos.alias))
El Optimizador va a tener dificultades en optimizar esto. Con los INNER JOIN y LEFT OUTER JOIN del SQL'92 te queda un código mucho más legible, y ayudas al optimizador.
Saludos.