Perché mysql utilizza l'indice errato per ordine per query?

Ecco la mia tabella con ~ 10.000.000 di righe di dati

CREATE TABLE `votes` (
  `subject_name` varchar(32) COLLATE utf8_unicode_ci NOT NULL,
  `subject_id` int(11) NOT NULL,
  `voter_id` int(11) NOT NULL,
  `rate` int(11) NOT NULL,
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`subject_name`,`subject_id`,`voter_id`),
  KEY `IDX_518B7ACFEBB4B8AD` (`voter_id`),
  KEY `subject_timestamp` (`subject_name`,`subject_id`,`updated_at`),
  KEY `voter_timestamp` (`voter_id`,`updated_at`),
  CONSTRAINT `FK_518B7ACFEBB4B8AD` FOREIGN KEY (`voter_id`) REFERENCES `users` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Ecco le cardinalità degli indici

Quindi quando faccio questa domanda:

SELECT SQL_NO_CACHE * FROM votes WHERE 
    voter_id = 1099 AND 
    rate = 1 AND 
    subject_name = 'medium'
ORDER BY updated_at DESC
LIMIT 20 OFFSET 100;

Mi aspettavo che usasse l'indice voter_timestamp ma mysql ha scelto di usare questo invece:

explain select SQL_NO_CACHE * from votes  where subject_name = 'medium' and voter_id = 1001 and rate = 1 order by updated_at desc limit 20 offset 100;`

type:
    index_merge
possible_keys: 
    PRIMARY,IDX_518B7ACFEBB4B8AD,subject_timestamp,voter_timestamp
key:
    IDX_518B7ACFEBB4B8AD,PRIMARY
key_len:
    102,98
ref:
    NULL
rows:
    9255
filtered:
    10.00
Extra:
    Using intersect(IDX_518B7ACFEBB4B8AD,PRIMARY); Using where; Using filesort

E ho ottenuto un tempo di interrogazione di 200-400 ms.

Se lo costringo a usare l'indice giusto come:

SELECT SQL_NO_CACHE * FROM votes USE INDEX (voter_timestamp) WHERE 
    voter_id = 1099 AND 
    rate = 1 AND 
    subject_name = 'medium'
ORDER BY updated_at DESC
LIMIT 20 OFFSET 100;

Mysql può restituire i risultati in 1-2ms

ed ecco la spiegazione:

type:
    ref
possible_keys:
    voter_timestamp
key:
    voter_timestamp
key_len:
    4
ref:
    const
rows:
    18714
filtered:
    1.00
Extra:
    Using where

Allora perché mysql non ha scelto l' voter_timestampindice per la mia query originale?

Quello che avevo provato è analyze table votes, optimize table voteseliminare quell'indice e aggiungerlo di nuovo, ma mysql utilizza ancora l'indice errato. non capisco bene qual è il problema.

MySQL sta utilizzando un modello di costo relativamente semplice (più semplice rispetto agli altri RDBMS) per pianificare query in cui il filtraggio del set di dati ha una priorità piuttosto elevata. Nella tua prima query con l'indice di unione si stima che sarà necessaria la scansione di ~ 9000 righe mentre la seconda con l'indice dell'indice richiederà 18000. La mia scommessa sarebbe che questo pesa nel calcolo abbastanza da spostare la scala verso l'unione . Puoi confermarlo (o trovare altri motivi) accendendo optimizer_trace, eseguendo la query e valutando i risultati.

set global optimizer_trace='enabled=on';

-- run your query 

SELECT SQL_NO_CACHE * FROM votes WHERE 
    voter_id = 1099 AND 
    rate = 1 AND 
    subject_name = 'medium'
ORDER BY updated_at DESC
LIMIT 20 OFFSET 100;

select * from information_schema.`OPTIMIZER_TRACE`;

Un'osservazione su index_merge: nella maggior parte dei casi scoprirai che è piuttosto costoso. Sebbene sia molto utile per gli scenari di tipo OLAP, potrebbe non essere molto adatto per OLTP poiché l'operazione può richiedere un tempo significativo della query e, come si può vedere, a volte il piano di esecuzione non ottimale è in realtà più veloce.

Fortunatamente MySQL fornisce switch per l'ottimizzatore in modo che tu possa personalizzarlo come desideri.

Per tutte le opzioni è possibile eseguire:

show global variables like 'optimizer_switch';

Per cambiarne uno non è necessario copiare incollare l'intera stringa. Funziona come dict.update()in Python.

 set global optimizer_switch='index_merge=off';

Se possibile, darei anche un'occhiata alla struttura del tuo tavolo e migliorerò. Avere una chiave primaria di ~ 100 byte con molte chiavi secondarie non è davvero consigliato.

Hai quattro chiavi secondarie e alcune di esse sono superflue, ad esempio (voter_id)index è un sottoinsieme di(voter_id, updated_at)

Per quella query, è necessario questo indice:

INDEX(voter_id, rate, subject_name, updated_at)

L' updated_atdeve essere l'ultima; gli altri tre possono essere in qualsiasi ordine. (Gli indici a 3 colonne di ypercube non sono molto utili poiché non finiscono le WHEREcolonne prima di colpire la ORDER BYcolonna.)

Quando aggiungi questo indice, probabilmente puoi sbarazzarti di tutte le altre chiavi secondarie:

KEY IDX_518B7ACFEBB4B8AD( voter_id), - L'FK può usare la mia chiave di indice subject_timestamp( subject_name, subject_id, updated_at), - KEY lo più ridondante voter_timestamp( voter_id, updated_at), - potrebbe essere stato il tentativo di

Con l'indice a 4 colonne, hai la possibilità di ottimizzare la "impaginazione" ed evitare OFFSET. Vedi questo blog

Su un altro argomento ... Quando vedo X_namee X_idpresumo che la "normalizzazione" stia succedendo. Mi aspetterei di vedere quelle due colonne in una tabella, praticamente nient'altro. Non mi aspetterei di vedere entrambi in qualche altra tabella.

(voter_id, updated_at)non passerà voter_idpoiché non ha terminato il filtro (il WHERE). Quindi, poiché l'altro indice è più piccolo, viene raccolto. Il mio ha 3 colonne per occuparsi del filtraggio, quindi la colonna per ORDER BY.