DBAtlas · Atlas d'exploitation des bases de données

Consulter/modifier les réglages de l'optimiseur / du parallélisme

Oracle

SHOW PARAMETER optimizer;
-- Session: ALTER SESSION SET optimizer_mode = FIRST_ROWS_10;
-- Parallelism: ALTER SESSION FORCE PARALLEL QUERY PARALLEL 4;

Des réglages comme optimizer_index_cost_adj et parallel_degree_policy influencent le choix des plans ; modifiez-les avec prudence.

PostgreSQL

SHOW random_page_cost;
SHOW max_parallel_workers_per_gather;
-- Session: SET enable_seqscan = off;

Sur SSD, random_page_cost ~1.1 est recommandé. Les flags enable_* servent au diagnostic, pas de correctif permanent.

MySQL

SELECT @@optimizer_switch;
SET SESSION optimizer_switch='index_merge=off';

optimizer_switch active/désactive des optimisations individuelles ; testez au niveau session.

SQL Server

-- Instance-level MAXDOP and cost threshold:
EXEC sp_configure 'max degree of parallelism', 8; RECONFIGURE;
-- Database level: ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 8;

MAXDOP=0 signifie illimité ; généralement 4-8 pour l'OLTP. La valeur par défaut de 5 pour « cost threshold for parallelism » est trop basse dans la plupart des cas.

MongoDB

# There are no optimizer parameters; indexes and query shape are decisive.
db.customer.find({...}).explain('allPlansExecution')

allPlansExecution affiche tous les plans évalués par le planificateur.

Redis

# Not applicable.

Il n'y a pas de planificateur ; io-threads et le choix de structure de données déterminent les performances.

Elasticsearch

GET <index>/_settings?include_defaults=true
# search limits such as search.max_buckets, index.max_result_window

Il n'y a pas d'optimiseur ; le nombre de shards, le routing et la structure des requêtes déterminent les performances.

Ouvrir dans DBAtlas →