Usar una caché de resultados / consultas

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;

Server Result Cache mantiene el resultado en la SGA; se invalida automáticamente cuando cambian las tablas subyacentes. RESULT_CACHE_MODE=FORCE lo aplica a todas las consultas elegibles, MANUAL solo mediante el hint. Poco beneficio en tablas que cambian con frecuencia.

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 no ofrece una caché de resultados de consultas; use una vista materializada (REFRESH manual/programado) o una caché a nivel de aplicación (Redis). Nota: el nodo Memoize proporciona caché a nivel de fila dentro de un nested loop, no caché de resultados de consultas.

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;

El antiguo query_cache_type se eliminó por completo en MySQL 8.0 (por problemas de escalabilidad). Use en su lugar el buffer pool de InnoDB, tablas resumen o una caché externa (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 no mantiene una caché de resultados (mantiene una caché de planes). Para agregaciones repetidas, una vista indexada se mantiene automáticamente; la coincidencia automática en los planes solo existe en la edición Enterprise (y Developer), mientras que en Standard la vista debe consultarse con el hint WITH (NOEXPAND); además, el buffer pool mantiene en memoria las páginas leídas con frecuencia.

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 no ofrece una caché de resultados; WiredTiger mantiene en memoria los datos de acceso frecuente. Para agregaciones costosas, use una colección resumen precalculada mediante $merge/$out o una caché de aplicación (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.

El patrón cache-aside habitual: si la clave existe, devuélvala rápidamente con GET; de lo contrario, calcule desde el origen y haga SET con EX (TTL). Redis suele servir como caché de resultados para otras bases de datos.

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 }

La shard request cache almacena los resultados por shard de las solicitudes size:0 (solo agregación); se invalida cuando el índice hace refresh. Las consultas con size>0 (que devuelven hits) no se cachean por defecto.