Tengo una tabla con varios millones de filas, desde la cual necesito ejecutar algunas consultas de vez en cuando. La primera consulta suele ser bastante lenta (alrededor de 10 segundos), y las consultas posteriores suelen ser mucho más rápidas (alrededor de 1 segundo). Después de algunas horas, un ciclo lento / luego rápido comienza nuevamente.
Verifiqué en mi plan de ejecución que todos los índices necesarios estuvieran presentes y se usaran adecuadamente, y supongo que la diferencia de rendimiento se debe al hecho de que el índice está realmente en la memoria para las consultas posteriores (estoy en lo cierto o hay otro ¿Posibles Causas?)
También estoy ejecutando muchas otras consultas usando índices, pero esas consultas requieren menos tiempo y su rendimiento es menos crítico, por lo que me preocupa que esos índices realmente estén sacando mi índice crítico de la memoria caché.
Además de la solución obvia de 'agregar más RAM', he estado pensando en realizar scripts de consultas ficticias que se ejecutan cada hora para forzar el índice de nuevo en la memoria.
¿Hay alguna forma más elegante de hacer esto? ¿Como una manera de insinuar SQLServer que si solo tiene suficiente memoria para mantener un solo índice en caché, debería ser ese?
Sé que, por lo general, lo mejor es no estropear el servidor SQLServer con respecto a ese tipo de cosas, pero la naturaleza inusual de mi consulta (se ejecuta muy raramente, pero con un tiempo crítico) me hace creer que tendría sentido (si es posible) .
También tengo curiosidad por saber si hay una manera de saber qué índices se almacenan en la memoria caché en un momento dado.