Eu tenho uma tabela com vários milhões de linhas, da qual preciso executar algumas consultas periodicamente. A primeira consulta geralmente será bastante lenta (cerca de 10s) e as consultas subsequentes geralmente são muito mais rápidas (cerca de 1s). Após algumas horas, um ciclo lento / rápido começa novamente.
Eu verifiquei no meu plano de execução se todo o índice necessário estava presente e usado apropriadamente e presumo que a diferença de desempenho se deva ao fato de o índice estar realmente na memória para as consultas subseqüentes (estou certo ou há outro Causas Possíveis?)
Também estou executando muitas outras consultas usando índices, mas essas consultas consomem menos tempo e seu desempenho é menos crítico, por isso estou preocupado que esses índices estejam realmente empurrando meu índice crítico para fora do cache de memória.
Além da correção óbvia de 'adicionar mais RAM', estive pensando em consultas fictícias de script a cada hora para forçar o índice de volta à memória.
Existe uma maneira mais elegante de fazer isso? Como uma maneira de sugerir ao SQLServer que, se ele tiver memória suficiente para manter um único índice em cache, deve ser esse?
Eu sei que geralmente a melhor coisa é não atrapalhar o SQLServer com relação a esse tipo de coisa, mas a natureza incomum da minha consulta (é executada muito raramente, mas com tempo crítico) me faz acreditar que faria sentido (se possível) .
Também estou curioso para saber se há uma maneira de saber quais índices são armazenados em cache na memória em um determinado momento?
fonte
Tente usar
KEEPPLAN
eKEEPPLAN FIXED
consultar dicas .KEEPPLAN força o otimizador de consulta a relaxar o limite de recompilação estimado para uma consulta.
KEEPFIXED PLAN força o otimizador de consulta a não recompilar uma consulta devido a alterações nas estatísticas. A especificação de KEEPFIXED PLAN assegura que uma consulta seja recompilada apenas se o esquema das tabelas subjacentes for alterado ou se sp_recompile for executado nessas tabelas.
fonte