クエリの実行計画を固定/強制(プランベースライン/ヒント)

Oracle

-- Load the good plan from the cursor cache as a baseline:
DECLARE n NUMBER; BEGIN
  n := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(sql_id => '&sql_id');
END;
/

SQL Plan Management は実行計画を固定する。劣化に対する最も強力な保護。/*+ ... */ ヒントも使用できる。

PostgreSQL

-- There is no built-in plan pinning; the pg_hint_plan extension:
/*+ IndexScan(customer customer_city_idx) */ SELECT ... ;

代替手段: enable_seqscan などの設定でセッションレベルで誘導する。永続的な固定には pg_hint_plan を使用する。

MySQL

SELECT /*+ INDEX(customer customer_city_idx) */ * FROM customer WHERE city='Ankara';

オプティマイザヒントはクエリに埋め込む。永続的な書き換えには query rewrite プラグインを使用する。

SQL Server

-- Force the good plan in Query Store:
EXEC sp_query_store_force_plan @query_id = 42, @plan_id = 17;

Query Store が有効である必要がある。代わりに OPTION (USE PLAN N'...') またはプランガイドも使用できる。

MongoDB

// Force an index for the query:
db.customer.find({ city: "Ankara" }).hint({ city: 1 })
// Persistent: db.customer.getPlanCache() / index filter

hint は特定のインデックスを強制する。古い実行計画は planCacheClear で消去する。

Redis

# Not applicable: there is no query planner.

パフォーマンスはデータ構造とコマンドの計算量で決まる。

Elasticsearch

# There is no plan pinning; optimize the query/index and routing.
GET <index>/_search { "profile": true, "query": {...} }

profile でどのクエリが高コストかを確認し、shards/routing で誘導する。