Gerenciar bind variables / parameter sniffing

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 variables reduzem os hard parses. O Adaptive Cursor Sharing atenua problemas de sniffing mantendo vários planos para valores de bind com distribuição assimétrica. Use cursor_sharing=FORCE com cuidado.

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 escolhe entre planos genéricos e personalizados; force_custom_plan gera um plano específico para os parâmetros a cada execução (uma solução para problemas semelhantes a sniffing).

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 evitam SQL injection e reduzem o custo de parsing. O MySQL também suporta parametrização no nível do driver.

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) gera um plano específico para os parâmetros a cada execução (caro em CPU). OPTIMIZE FOR fixa o plano em um valor específico/típico; OPTIMIZE FOR UNKNOWN usa a seletividade média.

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()

Consultas com o mesmo formato (mesmos campos/operadores) compartilham o plano em cache; valores literais diferentes não geram um novo plano. Se a distribuição dos valores for muito assimétrica, redefina com planCacheClear.

Redis

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

Os comandos são executados diretamente; o design das chaves, e não a parametrização, determina o desempenho.

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" } }

Um search template (Mustache) parametriza o corpo da consulta; a aplicação chama um template fixo com valores diferentes, melhorando a consistência das consultas e o uso do cache.