Mise en cache des requêtes SQL

Question

Si je regarde dans mon profileur pour SQL serveur, il est livré avec beaucoup de requêtes en double telles que:

exec sp_executesql N'SELECT * 
FROM [dbo].[tblSpecifications] AS [t0] 
WHERE [t0].[clientID] = @p0 
ORDER BY [t0].[Title]', N'@p0 int', @p0 = 21 

Beaucoup de ces requêtes ne sont pas nécessaires pour afficher les données en temps réel, c'est-à-dire que si quelqu'un insérait un nouvel enregistrement correspondant à cette requête, cela n'aurait pas d'importance s'il ne s'affichait pas jusqu'à une heure après l'insertion.

Vous pouvez afficher en cache les pages asp.net, mais je me demandais s'il y avait des fonctionnalités similaires sur le dbms (serveur SQL en particulier), qui enregistre une requête dans un cache et renouvelle ce cache après une période définie de temps, disons 1 heure, dans le but d'améliorer les vitesses de récupération des enregistrements.

Answer 1

Dans SQL Server 2000 et avant, vous pouvez utiliser DBCC PINTABLE (DatabaseID, tableid), mais de son mieux pour permettre à SQL Server pour gérer votre mémoire

Si vous avez une requête globale coûteuse que vous souhaitez « mises en cache ", créez une vue indexée pour matérialiser les résultats. Dans le cas contraire, la durée pendant laquelle une page de base de données reste en mémoire est déterminée par la règle la moins récemment utilisée. L'en-tête de chaque page de données dans le cache stocke des détails sur les deux dernières fois où il a été accédé. Un processus d'arrière-plan analyse le cache et décrémente un compte d'utilisateur si la page n'a pas été consultée depuis la dernière analyse. Lorsque SQL Server doit libérer le cache, les pages dont le nombre d'abonnés est le plus faible sont vidées en premier. (Professional SQL Server 2008 Internes et dépannage)

sys.dm_os_buffer_descriptors contient une ligne pour chaque page de données actuellement dans le cache

Answer 2

Non, mais il y a une tonne de solutions de mise en cache là-bas comme http://memcached.org/ http://ehcache.org/

Answer 3

résultats des requêtes sont pas mises en cache, mais les pages de données eux-mêmes resteront dans le cache jusqu'à ce qu'ils sont expulsés par d'autres opérations de lecture. La prochaine fois que votre requête sera soumise, ces pages seront lues de la mémoire au lieu du disque.

Ceci est une raison principale pour éviter les balayages de table lorsque cela est possible. Si la table analysée est suffisamment grande, votre cache est inondé de données potentiellement inutiles. Beaucoup de gens ont une attitude «qui se soucie de la durée de la requête, c'est l'exécution en mode batch», mais ils ne voient pas l'impact sur d'autres processus, comme celui que vous avez mentionné.

Answer 4

A ne pas manquer l'évidence, vous pouvez également créer une table de reporting entièrement séparée et mettre à jour toutes les heures. Bien qu'il y ait un coût pour le peupler et l'administrer, vous pouvez limiter les champs à ce qui est nécessaire et optimiser les index pour les lectures.