쿼리 실행 계획 고정 / 강제(plan baseline / hint)

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'...')이나 plan guide를 사용한다.

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로 어떤 쿼리가 비용이 큰지 확인한다. 샤드/routing으로 유도한다.