Partition Pruning prüfen

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 zeigen, dass nur die relevanten Partitionen gelesen werden (ideal ist eine Zahl statt KEY). Eine Funktion/implizite Konvertierung auf dem Partitionsschlüssel verhindert Pruning.

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.

Ist enable_partition_pruning aktiv, erscheinen nur passende Partitionen im Plan; die übrigen werden als 'never executed' angezeigt. Konstante Werte werden zur Planzeit, Parameter zur Ausführungszeit gepruned.

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)

Ab MySQL 5.7 listet die Spalte 'partitions' der einfachen EXPLAIN-Ausgabe die zu scannenden Partitionen (die Syntax EXPLAIN PARTITIONS wurde in 8.0 entfernt); es sollten nur die relevanten Partitionen erscheinen. Werden alle Partitionen aufgeführt, findet kein Pruning statt.

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.

Die Funktion $PARTITION liefert die Partitionsnummer eines Werts. Liegt die Anzahl der im tatsächlichen Ausführungsplan zugegriffenen Partitionen nahe 1, ist Pruning aktiv; werden alle Partitionen gescannt, passt das Prädikat nicht.

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'.

Enthält die Abfrage den Shard Key, leitet mongos sie nur an den relevanten Shard (targeted); andernfalls geht sie an alle Shards (Scatter-Gather). Prüfe die angesprochenen Shards in der explain-Ausgabe.

Redis

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

Die Daten werden über die Hash-Slots des Clusters verteilt; statt Query Pruning erfolgt der Schlüsselzugriff direkt.

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 beschränkt die Abfrage auf einen einzigen Shard (ähnlich Pruning). Bei Zeitreihendaten sorgt ein Indexname mit Datumsmuster (sale-2026-01) dafür, dass nur die relevanten Indizes durchsucht werden; nutze ein enges Muster statt eines Wildcards.