Кэш результатов / запросов

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 хранит результат в SGA; он автоматически инвалидируется при изменении базовых таблиц. RESULT_CACHE_MODE=FORCE применяет его ко всем подходящим запросам, MANUAL — только через хинт. На часто меняющихся таблицах пользы мало.

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 не предлагает кэша результатов запросов; используйте материализованное представление (REFRESH вручную/по расписанию) или кэш на уровне приложения (Redis). Примечание: узел Memoize обеспечивает кэширование строк внутри nested loop, а не кэширование результатов запросов.

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;

Старый query_cache_type полностью удалён в MySQL 8.0 (из-за проблем масштабируемости). Вместо него используйте InnoDB buffer pool, сводные таблицы или внешний кэш (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 не хранит кэш результатов (хранит кэш планов). Для повторяющихся агрегаций индексированное представление поддерживается автоматически; автоматическое сопоставление в планах есть только в редакции Enterprise (и Developer), а в Standard к представлению нужно обращаться с хинтом WITH (NOEXPAND); кроме того, buffer pool держит часто читаемые страницы в памяти.

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 не предлагает кэша результатов; WiredTiger держит часто используемые данные в памяти. Для дорогих агрегаций используйте предвычисленную сводную коллекцию через $merge/$out или кэш приложения (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.

Распространённый паттерн cache-aside: если ключ есть, быстро верните его через GET; иначе вычислите из источника и выполните SET с EX (TTL). Redis обычно служит кэшем результатов для других баз.

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 }

Shard request cache кэширует результаты по шардам для запросов с size:0 (только агрегации); инвалидируется при refresh индекса. Запросы с size>0 (возвращающие hits) по умолчанию не кэшируются.