Ergebnis-/Query-Cache nutzen

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;

Der Server Result Cache hält das Ergebnis in der SGA; er wird automatisch invalidiert, wenn sich die zugrunde liegenden Tabellen ändern. RESULT_CACHE_MODE=FORCE wendet ihn auf alle geeigneten Abfragen an, MANUAL nur per Hint. Bei häufig geänderten Tabellen bringt er wenig.

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 bietet keinen Cache für Abfrageergebnisse; nutze eine Materialized View (manuelles/geplantes REFRESH) oder einen Cache auf Anwendungsebene (Redis). Hinweis: Der Memoize-Knoten bietet Caching auf Zeilenebene innerhalb eines Nested Loop, kein Caching von Abfrageergebnissen.

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;

Das alte query_cache_type wurde in MySQL 8.0 vollständig entfernt (wegen Skalierungsproblemen). Nutze stattdessen den InnoDB Buffer Pool, Summentabellen oder einen externen Cache (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 hält keinen Ergebnis-Cache (er hält einen Plan-Cache). Für wiederholte Aggregationen wird eine Indexed View automatisch gepflegt; automatisches Matching in Plänen gibt es nur in der Enterprise- (und Developer-)Edition, unter Standard muss die View mit dem Hint WITH (NOEXPAND) abgefragt werden; zusätzlich hält der Buffer Pool häufig gelesene Seiten im Speicher.

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 bietet keinen Ergebnis-Cache; WiredTiger hält häufig genutzte Daten im Speicher. Für teure Aggregationen nutze eine vorberechnete Summen-Collection per $merge/$out oder einen Anwendungscache (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.

Das übliche Cache-aside-Muster: Existiert der Schlüssel, liefere ihn schnell mit GET; andernfalls aus der Quelle berechnen und mit SET samt EX (TTL) speichern. Redis dient meist als Ergebnis-Cache für andere Datenbanken.

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 }

Der Shard Request Cache cacht die Ergebnisse pro Shard für Anfragen mit size:0 (nur Aggregation); er wird beim Refresh des Index invalidiert. Abfragen mit size>0 (die Treffer liefern) werden standardmäßig nicht gecacht.