Проверить отсечение секций (partition pruning)

Oracle

EXPLAIN PLAN FOR
SELECT * FROM sale WHERE sale_date = DATE '2026-01-15';
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
-- Look for 'PARTITION RANGE ITERATOR/SINGLE' and the Pstart/Pstop columns in the plan.

Pstart/Pstop показывают, что читаются только нужные секции (идеально — число, а не KEY). Применение функции/неявного преобразования к ключу секционирования мешает отсечению.

PostgreSQL

SET enable_partition_pruning = on;
EXPLAIN (ANALYZE)
SELECT * FROM sale WHERE sale_date = DATE '2026-01-15';
-- Verify in the plan that only the relevant partition (child table) is scanned.

При включённом enable_partition_pruning в плане есть только подходящие секции; остальные помечены 'never executed'. Константы отсекаются при построении плана, параметры — при выполнении.

MySQL

-- Show which partitions are scanned:
EXPLAIN SELECT * FROM sale WHERE sale_date = '2026-01-15';
-- 5.7 and earlier: EXPLAIN PARTITIONS SELECT ... (removed in 8.0)

В MySQL 5.7+ столбец 'partitions' обычного вывода EXPLAIN перечисляет сканируемые секции (синтаксис EXPLAIN PARTITIONS удалён в 8.0); должны быть только нужные секции. Если перечислены все секции, отсечение не происходит.

SQL Server

-- Find which partition a value falls into:
SELECT $PARTITION.pf_sale_date('2026-01-15') AS partition_no;
-- Examine 'Actual Partition Count' and 'Actual Partitions Accessed' in the actual plan.

Функция $PARTITION возвращает номер секции для значения. Если число секций, к которым обращается фактический план выполнения, близко к 1, отсечение работает; если сканируются все секции, предикат не подходит.

MongoDB

// Targeted query using the shard key in a sharded cluster:
db.sale.find({ shop_id: 42 }).explain("executionStats")
// In explain, only the relevant shard should appear under 'shards'.

Если запрос содержит shard key, mongos направляет его только на нужный шард (targeted); иначе он рассылается на все шарды (scatter-gather). Проверьте задействованные шарды в выводе explain.

Redis

# Not applicable: there is no table/partition concept.

Данные распределяются через hash slots Cluster; вместо отсечения запросов доступ по ключу прямой.

Elasticsearch

# Route to the relevant shard with routing:
GET <index>/_search?routing=customer42
{ "query": { "term": { "customer_id": 42 } } }
# Query only the relevant indices with a time-based index pattern:
GET sale-2026-01/_search

Custom routing сужает запрос до одного шарда (аналог отсечения). Для данных временных рядов имя индекса с шаблоном даты (sale-2026-01) обеспечивает поиск только в нужных индексах; используйте узкий шаблон вместо wildcard.