Utiliser un cache de résultats / de requêtes

Oracle

-- Result cache at query level:
SELECT /*+ RESULT_CACHE */ city, COUNT(*) FROM customer GROUP BY city;
-- Global mode: ALTER SYSTEM SET result_cache_mode = FORCE;

Le Server Result Cache conserve le résultat dans la SGA ; il est invalidé automatiquement lorsque les tables sous-jacentes changent. RESULT_CACHE_MODE=FORCE l'applique à toutes les requêtes éligibles, MANUAL uniquement via le hint. Peu d'intérêt sur les tables qui changent souvent.

PostgreSQL

-- There is no built-in result cache.
-- Precompute with a materialized view:
CREATE MATERIALIZED VIEW mv_city_summary AS
  SELECT city, COUNT(*) FROM customer GROUP BY city;
REFRESH MATERIALIZED VIEW mv_city_summary;

PostgreSQL n'offre pas de cache de résultats de requêtes ; utilisez une vue matérialisée (REFRESH manuel/planifié) ou un cache applicatif (Redis). Remarque : le nœud Memoize assure un cache au niveau ligne dans une nested loop, pas un cache des résultats de requêtes.

MySQL

-- Query Cache was REMOVED in MySQL 8.0.
-- Alternative: a materialized summary table or an application cache:
CREATE TABLE city_summary AS SELECT city, COUNT(*) c FROM customer GROUP BY city;

L'ancien query_cache_type a été entièrement supprimé dans MySQL 8.0 (pour des problèmes de scalabilité). Utilisez à la place le buffer pool InnoDB, des tables de synthèse ou un cache externe (Redis/Memcached).

SQL Server

-- There is no built-in query result cache.
-- Precompute with an indexed (materialized) view:
CREATE VIEW dbo.vw_city_summary WITH SCHEMABINDING AS
  SELECT city, COUNT_BIG(*) c FROM dbo.customer GROUP BY city;
CREATE UNIQUE CLUSTERED INDEX ix ON dbo.vw_city_summary(city);

SQL Server ne conserve pas de cache de résultats (il conserve un plan cache). Pour les agrégations répétées, une vue indexée est maintenue automatiquement ; la correspondance automatique dans les plans n'existe qu'en édition Enterprise (et Developer), tandis qu'en Standard la vue doit être interrogée avec le hint WITH (NOEXPAND) ; en outre, le buffer pool garde en mémoire les pages fréquemment lues.

MongoDB

// There is no built-in query result cache.
// Pre-aggregate and write to a collection ($merge):
db.sale.aggregate([
  { $group: { _id: "$city", t: { $sum: "$amount" } } },
  { $merge: "city_summary" }
])

MongoDB n'offre pas de cache de résultats ; WiredTiger garde en mémoire les données fréquemment consultées. Pour les agrégations coûteuses, utilisez une collection de synthèse précalculée via $merge/$out ou un cache applicatif (Redis).

Redis

# Redis is already a cache layer; cache the result manually:
SET query:city_summary "{...}" EX 300
GET query:city_summary
# If already computed, return it with GET; otherwise compute it and write it with SET.

Le schéma cache-aside courant : si la clé existe, renvoyez-la rapidement avec GET ; sinon calculez depuis la source et faites un SET avec EX (TTL). Redis sert généralement de cache de résultats pour d'autres bases.

Elasticsearch

# Shard request cache (enabled by default for size:0 aggregations):
GET <index>/_search?request_cache=true
{ "size": 0, "aggs": { "city": { "terms": { "field": "city" } } } }
# Setting: PUT <index>/_settings { "index.requests.cache.enable": true }

Le shard request cache met en cache les résultats par shard des requêtes size:0 (agrégation seule) ; il est invalidé lors du refresh de l'index. Les requêtes avec size>0 (qui renvoient des hits) ne sont pas mises en cache par défaut.