Qual è il significato di filtrato in MySQL spiegare?

Come descritto qui nei documenti MySQL :

La colonna filtrata indica una percentuale stimata di righe della tabella che verranno filtrate dalla condizione della tabella. Cioè, righe mostra il numero stimato di righe esaminate e righe × filtrate / 100 mostra il numero di righe che verranno unite con le tabelle precedenti. Prima di MySQL 5.7.3, questa colonna viene visualizzata se si utilizza EXPLAIN EXTENDED. A partire da MySQL 5.7.3, l'output esteso è abilitato per impostazione predefinita e la parola chiave EXTENDED non è necessaria.

Ancora non capisco. Qual è il significato di "filtrato" qui? Quali informazioni possiamo ottenere da questa colonna?

Ad esempio, quando inizio la query, alcune query visualizzeranno 100 e altre mostreranno 18 o qualsiasi valore inferiore a 100.

+-------------+-------+--------+---------+---------+------+----------+
| select_type | table | type   | key     | key_len | rows | filtered |
+-------------+-------+--------+---------+---------+------+----------+
| PRIMARY     | a     | range  | search  | 4       |  174 |   18.00  | <--
| PRIMARY     | b     | eq_ref | PRIMARY | 4       |    1 |   100.00 |
| PRIMARY     | c     | ALL    | PRIMARY | 4       |    1 |   100.00 |

Qual è il punto principale che possiamo concludere da questo valore?

Dice che la colonna ha filtrato solo il 18%? O se più basso è il punteggio, migliore è l'indice / query?

Sto usando MySQL 5.7

Filtrare qui significa applicare una condizione su un insieme di righe selezionate da una typericerca come potenziali righe e mantenere solo le righe che soddisfano la condizione:

MySQL proverà innanzitutto a utilizzare un indice, ad esempio eseguendo una rangescansione sulla tabella autilizzando il searchtasto-. Si stima di ottenere 174 righe dall'uso di quell'indice, che è il numero in rows. Questo passaggio non è ancora chiamato filtro.

Successivamente, queste 174 righe devono essere verificate in base a condizioni aggiuntive (di solito nel tuo where-clause). MySQL ora stima che solo 32 righe, quindi il 18% di queste 174 righe, rimarranno dopo l'applicazione del filtro. Questo 18% è il valore in filtered.

Mentre è ovviamente meglio avere 32 righe invece di 174 (se ad esempio è necessario in un secondo momento joincon un'altra tabella), un indice "perfetto" ti avrebbe dato queste 32 righe direttamente dalla ricerca iniziale, risparmiando il tempo di guardare e filtrare l'82% di tutte le potenziali righe.

Quindi un valore basso potrebbe indicare che potrebbe esserci un indice migliore: ad esempio una scansione completa della tabella con rows=1000e filtered=0.1%potrebbe diventare una ricerca dell'indice con rows=1e filtered=100%se aggiungi un buon indice.

D'altra parte, puoi benissimo ignorare completamente questo filteredvalore (che è nella maggior parte dei casi una stima davvero negativa) e concentrarti sulle altre colonne più importanti (in particolare type, keye extra) per ottimizzare la tua query. Ad esempio può essere meglio sbarazzarsi di un filesort(ad esempio utilizzando un indice che soddisfa il order by), anche se si traduce in un filteredvalore inferiore . E un migliore typepuò comportare un enorme miglioramento delle prestazioni, anche se potrebbe non cambiare o addirittura abbassarsi filtered. Nell'esempio sopra con filtered=0.1%, type=allsarebbe già sufficiente indicare che potresti essere in grado di migliorare quella query aggiungendo un indice, senza guardare filteredaffatto.

Quindi non prendere troppo sul serio quel valore: né 100significa che i tuoi indici sono buoni, né un valore inferiore indica necessariamente indici cattivi. typeè un indicatore molto migliore per questo.