Кэширование результата ORM

ORM D7 умеет кэшировать результат выборки штатно — без обёртки в Cache API вручную. Параметр cache в getList, тегированный кэш и грамотная инвалидация снимают лишнюю нагрузку с БД на часто повторяющихся запросах.

Параметр cache в getList

Самый простой способ закэшировать выборку — передать в getList() параметр cache с временем жизни в секундах:

$rows = ProductTable::getList([
  'filter' => ['=ACTIVE' => 'Y'],
  'select' => ['ID', 'NAME', 'PRICE'],
  'cache' => ['ttl' => 3600],
])->fetchAll();

ORM сама вычислит ключ кэша по параметрам запроса (filter, select, order и т.д.) и положит результат в файловый или иной кэш согласно настройкам сайта. При повторном вызове с теми же параметрами SQL не выполнится, а данные вернутся из хранилища кэша. Это особенно заметно на страницах со множеством одинаковых выборок справочников: первый хит прогревает кэш, остальные читают готовый результат.

Кэширование запросов со связями

По умолчанию ORM не кэширует запросы с JOIN — из соображений корректной инвалидации. Чтобы разрешить кэш для выборок со связями, добавьте флаг cache_joins:

$rows = OrderTable::getList([
  'select' => ['ID', 'USER.NAME'],
  'cache' => ['ttl' => 1800, 'cache_joins' => true],
])->fetchAll();

Для объектного синтаксиса эквивалент — методы Query::setCacheTtl() и Query::cacheJoins(true). На практике cache_joins оправдан там, где связанная таблица меняется редко (справочники статусов, типов, валют), а основная выборка тяжёлая и повторяется часто.

Объектный синтаксис Query

При работе через объект Query кэш настраивается методами-сеттерами, что удобно для динамически собираемых запросов:

use Bitrix\Main\ORM\Query\Query;

$result = ProductTable::query()
  ->setSelect(['ID', 'NAME'])
  ->setFilter(['=ACTIVE' => 'Y'])
  ->setCacheTtl(3600)
  ->cacheJoins(true)
  ->exec()
  ->fetchAll();

Тегированный кэш и сброс

Проблема любого кэша — устаревание. Битрикс использует тегированный кэш: записи помечаются тегами, и при изменении данных теги сбрасываются, инвалидируя связанные записи. Для ORM-таблиц ядро само регистрирует теги вида имя_таблицы при включённом управляемом кэше.

• включите управляемый кэш: Настройки → Автокэширование → Управляемый кэш;
• методы сущности add()/update()/delete() сбрасывают тег своей таблицы автоматически;
• ручной сброс — через Application::getInstance()->getTaggedCache().

Пример ручной пометки и сброса тега:

$taggedCache = \Bitrix\Main\Application::getInstance()->getTaggedCache();
$taggedCache->clearByTag('my_product_table');

Инвалидация при записи

Когда вы меняете данные напрямую в БД (минуя ORM) или через внешний обмен, автоматический сброс тега не сработает — кэш отдаст устаревшие данные. В таких случаях инвалидируйте вручную:

// после массового импорта в таблицу
$cache = \Bitrix\Main\Application::getInstance()->getTaggedCache();
$cache->startTagCache('/orm');
$cache->registerTag('my_product_table');
$cache->endTagCache();
$cache->clearByTag('my_product_table');

Когда кэшировать, а когда нет

Кэш ORM — не универсальное решение. Оцените профиль запроса:

• кэшируйте выборки с ограниченным набором вариантов параметров;
• избегайте кэша для запросов, где фильтр почти всегда уникален — вы засорите хранилище;
• для тяжёлой аналитики комбинируйте ORM-кэш с внешним хранилищем (Memcached/Redis) через настройки кэша сайта.

Итог

Штатное кэширование ORM закрывает большинство сценариев: cache/ttl для простых выборок, cache_joins для связей, тегированный кэш для автоматической инвалидации через add()/update()/delete(). Главное — помнить про ручной сброс тегов при прямой записи в БД и не кэшировать запросы с уникальными фильтрами.

Мы в B2Bsite настраиваем кэширование и инвалидацию на высоконагруженных проектах Битрикс — от справочников до каталогов на десятки тысяч SKU. Если ваш сайт упирается в БД под нагрузкой, поможем выстроить многоуровневый кэш с корректным сбросом и предсказуемой производительностью.