J'ai une table avec plusieurs millions de lignes, à partir de laquelle je dois exécuter de temps en temps des requêtes. La première requête sera généralement assez lente (environ 10 secondes), et les requêtes suivantes sont généralement beaucoup plus rapides (environ 1 seconde). Après quelques heures, un cycle lent / puis rapide recommence.
J'ai vérifié dans mon plan d'exécution que tous les index nécessaires étaient présents et correctement utilisés, et je suppose que la différence de performances est due au fait que l'index est réellement en mémoire pour les requêtes suivantes (ai-je raison ou y en a-t-il d'autres causes possibles?)
J'exécute également de nombreuses autres requêtes à l'aide d'index, mais ces requêtes prennent moins de temps et leurs performances sont moins critiques.Je crains donc que ces index ne poussent mon index critique hors du cache mémoire.
Mis à part le correctif évident «ajouter plus de RAM», j'ai pensé à scripter des requêtes factices à exécuter toutes les heures pour forcer l'index à revenir en mémoire.
Existe-t-il une manière plus élégante de procéder? Comme un moyen d'indiquer à SQLServer que s'il ne dispose que de suffisamment de mémoire pour garder un seul index mis en cache, ce devrait être celui-ci?
Je sais que la meilleure chose à faire est généralement de ne pas gâcher le SQLServer en ce qui concerne ce genre de choses, mais la nature inhabituelle de ma requête (qui s'exécute très rarement, mais à temps critique) me fait croire que cela aurait du sens (si possible) .
Je suis également curieux de savoir s'il existe un moyen de savoir quels index sont mis en cache en mémoire à un moment donné?