Usar um cache de resultados / de 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;

O Server Result Cache mantém o resultado na SGA; é invalidado automaticamente quando as tabelas subjacentes mudam. RESULT_CACHE_MODE=FORCE o aplica a todas as consultas elegíveis; MANUAL, apenas via hint. Pouco benefício em tabelas que mudam com frequência.

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;

O PostgreSQL não oferece cache de resultados de consultas; use uma materialized view (REFRESH manual/agendado) ou um cache em nível de aplicação (Redis). Observação: o nó Memoize fornece cache em nível de linha dentro de um nested loop, não cache 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;

O antigo query_cache_type foi totalmente removido no MySQL 8.0 (devido a problemas de escalabilidade). Em vez disso, use o InnoDB buffer pool, tabelas de resumo ou um cache externo (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);

O SQL Server não mantém cache de resultados (mantém um plan cache). Para agregações repetidas, uma indexed view é mantida automaticamente; a correspondência automática nos planos existe apenas nas edições Enterprise (e Developer), enquanto na Standard a view deve ser consultada com o hint WITH (NOEXPAND); além disso, o buffer pool mantém em memória as páginas lidas com frequência.

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" }
])

O MongoDB não oferece cache de resultados; o WiredTiger mantém em memória os dados acessados com frequência. Para agregações caras, use uma coleção de resumo pré-calculada via $merge/$out ou um cache de aplicação (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.

O padrão cache-aside comum: se a chave existir, retorne-a rapidamente com GET; caso contrário, calcule a partir da origem e grave com SET usando EX (TTL). O Redis geralmente serve como cache de resultados para outros bancos de dados.

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 }

O shard request cache armazena em cache os resultados por shard de requisições size:0 (apenas agregação); é invalidado quando o índice faz refresh. Consultas com size>0 (que retornam hits) não são armazenadas em cache por padrão.