L'output EXPLAIN suggerisce che il mio indice non viene utilizzato

Ho impostato la mia tabella con un indice solo su done_status (done_status = INT):

inserisci qui la descrizione dell'immagine

Quando uso:

EXPLAIN SELECT * FROM reminder  WHERE done_status=2

Ricevo questo:

id select_type tipo di tabella chiave possible_keys key_len ref righe Extra
1 SEMPLICE promemoria TUTTO done_status NULL NULL NULL 5 Utilizzo di where

Ma quando emetto questo comando:

EXPLAIN SELECT * FROM reminder  WHERE done_status=1

Ricevo quanto segue:

id select_type tipo di tabella chiave possible_keys key_len ref righe Extra
1 SEMPLICE promemoria ref done_status done_status 4 const 2

Gli EXPLAINspettacoli me che utilizza 5 righe, la seconda volta 2 file.

Non penso che l'indice sia usato, se l'ho capito bene la prima volta dovrebbe darmi 3 righe. Cosa faccio di sbagliato?

SHOW INDEX FROM reminder:

Tabella Non_unique Nome_ chiave Seq_in_index Nome_colonna Fascicolazione Cardinalità Sotto_parte Confezionato Null Index_type Comment Index_comment
promemoria 1 done_status 1 done_status A 5 NULL NULL BTREE

spiegare esteso:

id select_type tabella tipo possible_keys chiave key_len ref righe filtrate Extra
1 SEMPLICE promemoria ref done_status done_status 4 const 2 100,00

show warnings non ha mostrato nulla di interessante.

mysql

— TasostheGreat
fonte

Fidati di me, l'indice funziona. Ma non riesco a vedere nulla facilmente nella tua schermata - puoi fare uno "show index from yourtable"

sì, ho modificato la mia domanda

usa glorify \ G per lo schema e spiega il risultato del piano, dovrebbe essere più leggibile

— ajreal

Per interesse puoi ripetere con un "spiegazione estesa" e un "mostra avvertimenti" questo mostrerà l'effettivo SQL mysql scelto

@ajreal cos'è glorify?

Risposte:

Hai frainteso quale sia il campo "righe". È il numero di righe che mysql stima che dovrà leggere per soddisfare la tua richiesta. Questo valore può essere abbastanza impreciso. Non significa che questo è il numero di righe nel risultato - o il numero effettivo di righe lette da mysql

Così? Dove ho detto che lo fa? Cosa sceglie l'ottimizzatore? L'indice funziona ancora.

@ajreal Tuttavia non significa che l'indice sia rotto. Solo l'ottimizzatore sceglie (nella sua mente) il modo più efficiente per interrogare i dati. Supponevo che l'OP si aspettasse che la colonna delle righe in EXPLAIN fosse esatta. Non significa che l'indice sia rotto - solo che mysql sceglie di non usarlo (probabilmente).

@ajreal: mi manca qualcosa nei tuoi punti. La colonna righe di una spiegazione non ha nulla a che fare con gli indici, giusto? Mysql sceglie di non usare l'indice (forse tutti i dati sono in una singola pagina). Non sei sicuro di capire il tuo punto? L'ottimizzazione delle query su una tabella a 5 righe produrrà alcuni risultati "dispari" perché praticamente non importa come ottimizzare.

dobbiamo continuare questa discussione in videochat

In questo caso, a chi importa quale indice sceglie l'ottimizzatore? Non c'è niente di sbagliato nell'indice stesso, perché l'ottimizzatore sembrava non averne bisogno: che importanza ha?

Il primo piano di esecuzione non fa sicuramente uso dell'indice,
potrebbe essere che information_schema.statistics sull'indice non riesca a raggiungere i dati dopo alcune operazioni di scrittura o non si accede alla tabella da molto tempo.

come spiegato qui: - Da dove MySQL Query Optimizer legge le statistiche dell'indice?

per il secondo piano di esecuzione, sembra che information_schema.statistics abbia già raggiunto e risolto il problema di cardinalità NULL.

Pertanto, viene eseguita la query in base all'ottimizzatore dell'indice.

Per le tabelle con piccole file, non importa molto.
Ma i dati cresceranno, lo sviluppatore dovrebbe sempre fare un controllo su questo
ed eseguire la tabella di analisi necessaria quando l'incontro con la cardinalità è nullo sull'indice.

— ajreal
fonte

Il primo piano di esecuzione non utilizza un indice.

Dal sito Web di riferimento MySQL :

Talvolta MySQL non utilizza un indice, anche se disponibile. Una circostanza in cui ciò si verifica è quando l'ottimizzatore stima che l'utilizzo dell'indice richiederebbe a MySQL di accedere a una percentuale molto grande delle righe nella tabella. (In questo caso, è probabile che una scansione delle tabelle sia molto più veloce perché richiede meno ricerche.) Tuttavia, se una query di questo tipo utilizza LIMIT per recuperare solo alcune delle righe, MySQL utilizza comunque un indice, poiché può trovare molto più rapidamente le poche righe da restituire nel risultato.

Se la tabella ha solo 5 righe e la query ne seleziona 3, l'ottimizzatore MySQL presuppone che sia più efficiente eseguire la scansione dell'intera tabella.

— Matthew Sammut
fonte