La variabile di stato di MySQL Handler_read_rnd_next sta crescendo molto

Nello stato MYSQL, il valore Handler_read_rnd_next è molto alto.

Sono consapevole che questo valore verrà incrementato quando viene eseguita una query che non ha indici adeguati.

Ma anche quando eseguiamo lo stato di show come 'Handler_read_rnd_next', questo valore viene incrementato di 2.

Sulla base di questo flag di stato, stiamo monitorando alcune statistiche.

Quindi, ogni volta, queste statistiche mostrano critiche.

Possiamo escludere questi conteggi di esecuzione 'show' dal conteggio 'Handler_read_rnd_next'.

Un altro esempio per questo,

Esiste una tabella con 10 righe, la tabella è indicizzata sulla colonna "dati" e se eseguiamo la seguente query:

select data from test where data = 'vwx' -> returns one row

e se controlliamo il valore di 'Handler_read_rnd_next', viene incrementato di 7.

Di seguito è riportato il risultato del comando esplicativo per la query sopra:

explain select data from test where data = 'vwx';

id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra

1, 'SIMPLE', 'test', 'ref', 'data', 'data', '35', 'const', 1, 'Using where; Using index'

Esiste un modo per limitare questo valore o posso sapere perché questo valore viene incrementato molto velocemente.

Prima di tutto, diamo un'occhiata alla definizione di Handler_read_rnd_next.

Secondo la documentazione MySQL su Handler_read_rnd_next:

Il numero di richieste per leggere la riga successiva nel file di dati. Questo valore è alto se si eseguono molte scansioni di tabelle. In genere ciò suggerisce che le tabelle non sono correttamente indicizzate o che le query non sono state scritte per sfruttare gli indici disponibili.

Ora guarda la tua query:

select data from test where data = 'vwx';

Hai detto che la tabella ha 10 righe. Come regola generale, lo Strumento per ottimizzare le query MySQL rifiuta l'uso di un indice se il numero di righe da esaminare è superiore al 5% del numero totale di righe.

Facciamo la matematica. Il 5% di 10 righe è 0,5 righe. Anche se il numero di righe necessario per individuare i dati è 1, questo è maggiore di 0,5. Sulla base di questo numero inferiore di righe e della regola dell'indice che ho appena menzionato, MySQL Query Optimizer eseguirà sempre una scansione della tabella.

Poiché la colonna datastessa è indicizzata, anziché una scansione di tabella, mysql ha eseguito una scansione di indice.

Se si è certi che la tabella di test non crescerà mai, è possibile rimuovere tutti gli indici e consentire l'esecuzione delle scansioni delle tabelle. Le variabili di stato del gestore dovrebbero interrompere l'incremento.

Quale versione di MySQL?

I motivi per cui questo flag viene incrementato è meglio documentato qui: http://www.mysqlperformanceblog.com/2010/06/15/what-does-handler_read_rnd-mean/

In breve, è solo il contatore del numero di righe recuperate in ordine durante una scansione della tabella completa o parziale.

Detto questo, sto ottenendo un risultato diverso:

mysql> CREATE TABLE `test` (
    ->   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    ->   `data` varchar(255) NOT NULL,
    ->   PRIMARY KEY (`id`),
    ->   KEY `data` (`data`)
    -> ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.27 sec)

mysql> INSERT INTO test (data) VALUES ('a'), ('b'), ('c'), ('d'), ('e'), ('f'), ('g'), ('h'), ('i'), ('vwx');
Query OK, 10 rows affected (0.06 sec)
Records: 10  Duplicates: 0  Warnings: 0

mysql> FLUSH STATUS;
Query OK, 0 rows affected (0.07 sec)

mysql> select data from test where data = 'vwx';
+------+
| data |
+------+
| vwx  |
+------+
1 row in set (0.04 sec)

mysql> SHOW SESSION STATUS LIKE 'Handler%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Handler_commit             | 1     |
| Handler_delete             | 0     |
| Handler_discover           | 0     |
| Handler_prepare            | 0     |
| Handler_read_first         | 0     |
| Handler_read_key           | 3     |
| Handler_read_last          | 0     |
| Handler_read_next          | 1     |
| Handler_read_prev          | 0     |
| Handler_read_rnd           | 0     |
| Handler_read_rnd_next      | 0     |
| Handler_rollback           | 0     |
| Handler_savepoint          | 0     |
| Handler_savepoint_rollback | 0     |
| Handler_update             | 0     |
| Handler_write              | 0     |
+----------------------------+-------+
16 rows in set (0.15 sec)

Se nella colonna "dati" è presente un indice unico / primario, hai già eseguito l'ottimizzazione per questa query. Non riesco a pensare che si possa fare un'ulteriore ottimizzazione su questo.

Inoltre puoi verificare se è stata eseguita la SCAN TABELLA COMPLETA o no?

SHOW STATUS like 'select_scan'; 
SELECT data from test where data='vmx';
SHOW STATUS like 'select_scan'; 

Assicurati che select_scan non abbia aumentato il suo valore, in questo modo puoi controllare se FAN TABLE SCAN è stato eseguito o meno, dovresti provare a ottimizzare una query che non eseguirà FULL TABLE SCAN.