Bind-Variablen / Parameter Sniffing verwalten

Oracle

-- Use binds instead of literals (for plan sharing):
SELECT * FROM customer WHERE city = :city;
-- Share legacy code that uses literals:
ALTER SESSION SET cursor_sharing = FORCE;

Bind-Variablen reduzieren Hard Parses. Adaptive Cursor Sharing entschärft Sniffing-Probleme, indem es für ungleich verteilte Bind-Werte mehrere Pläne vorhält. cursor_sharing=FORCE mit Vorsicht verwenden.

PostgreSQL

-- Parameterize with a prepared statement:
PREPARE q (text) AS SELECT * FROM customer WHERE city = $1;
EXECUTE q('Ankara');
-- Set plan cache behavior:
SET plan_cache_mode = force_custom_plan;

plan_cache_mode=auto wählt zwischen generischen und benutzerdefinierten Plänen; force_custom_plan erzeugt bei jeder Ausführung einen parameterspezifischen Plan (Abhilfe bei sniffing-ähnlichen Problemen).

MySQL

-- Server-side prepared statement:
PREPARE stmt FROM 'SELECT * FROM customer WHERE city = ?';
SET @city = 'Ankara';
EXECUTE stmt USING @city;
DEALLOCATE PREPARE stmt;

Prepared Statements verhindern SQL Injection und senken die Parsing-Kosten. MySQL unterstützt Parametrisierung auch auf Treiberebene.

SQL Server

-- Parameterized query (sp_executesql):
EXEC sp_executesql N'SELECT * FROM dbo.customer WHERE city = @city', N'@city nvarchar(50)', @city = N'Ankara';
-- Handle sniffing with a hint:
SELECT ... OPTION (RECOMPILE);
-- or OPTION (OPTIMIZE FOR (@city = 'Ankara'));

OPTION(RECOMPILE) erzeugt bei jeder Ausführung einen parameterspezifischen Plan (CPU-intensiv). OPTIMIZE FOR fixiert den Plan auf einen bestimmten/typischen Wert; OPTIMIZE FOR UNKNOWN nutzt die durchschnittliche Selektivität.

MongoDB

// The query shape is the key of the plan cache:
db.customer.find({ city: "Ankara" }).explain("queryPlanner")
// Clear a stale plan:
db.customer.getPlanCache().clear()

Abfragen mit derselben Form (gleiche Felder/Operatoren) teilen sich den gecachten Plan; andere Literalwerte erzeugen keinen neuen Plan. Ist die Werteverteilung stark ungleich, mit planCacheClear zurücksetzen.

Redis

# Not applicable: there is no query planner or parameter sniffing.

Befehle werden direkt ausgeführt; das Schlüsseldesign, nicht die Parametrisierung, bestimmt die Performance.

Elasticsearch

# Reuse the query with a parameterized search template:
POST _scripts/customer_city
{ "script": { "lang": "mustache", "source": { "query": { "term": { "city": "{{city}}" } } } } }
GET <index>/_search/template
{ "id": "customer_city", "params": { "city": "Ankara" } }

Ein Search Template (Mustache) parametrisiert den Abfragerumpf; die Anwendung ruft ein festes Template mit unterschiedlichen Werten auf, was Abfragekonsistenz und Cache-Nutzung verbessert.