Variabel status MySQL Handler_read_rnd_next tumbuh banyak


11

Dalam status MYSQL, nilai Handler_read_rnd_next sangat tinggi.

Saya menyadari bahwa, nilai ini akan bertambah ketika kueri dijalankan yang tidak memiliki indeks yang tepat.

Tetapi, bahkan ketika kita menjalankan status acara seperti 'Handler_read_rnd_next', nilai ini semakin bertambah 2.

Berdasarkan tanda status ini, kami memantau beberapa statistik.

Jadi setiap kali, statistik ini menunjukkan kritis.

Bisakah kita mengecualikan jumlah eksekusi 'tayang' ini dari hitungan 'Handler_read_rnd_next'.

Satu lagi contoh untuk ini,

Ada tabel dengan 10 baris, tabel diindeks pada kolom 'data', dan jika kita menjalankan kueri berikut:

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

dan jika kita memeriksa nilai 'Handler_read_rnd_next', itu bertambah 7.

Berikut ini adalah hasil dari menjelaskan perintah untuk permintaan di atas:

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'

Apakah ada cara untuk membatasi nilai ini, atau dapatkah saya tahu mengapa nilai ini bertambah sangat cepat.


Apakah ini benar-benar menyebabkan masalah kinerja?
Aaron Brown

Tidak ada kinerja yang tidak terpengaruh, tetapi alat pemantauan memeriksa tanda ini dan menunjukkan kritis.
Phanindra

Jika kinerja bukan masalah, maka perbaiki alat pemantauan sebagai gantinya.
Aaron Brown

Saya telah memeriksa dengan alat lain juga (Monyog), ada juga masalah yang sama.
Phanindra

terus? Abaikan saja jika itu tidak menyebabkan masalah kinerja. Itu hanya sebuah penghitung.
Aaron Brown

Jawaban:


5

Pertama-tama, mari kita lihat definisi Handler_read_rnd_next.

Menurut Dokumentasi MySQL di Handler_read_rnd_next:

Jumlah permintaan untuk membaca baris berikutnya dalam file data. Nilai ini tinggi jika Anda melakukan banyak pemindaian tabel. Secara umum ini menunjukkan bahwa tabel Anda tidak diindeks dengan benar atau bahwa permintaan Anda tidak ditulis untuk mengambil keuntungan dari indeks yang Anda miliki.

Sekarang, lihat permintaan Anda:

select data from test where data = 'vwx';

Anda mengatakan bahwa tabel memiliki 10 baris. Sebagai aturan praktis, Pengoptimal Permintaan MySQL akan mengabaikan penggunaan indeks jika jumlah baris yang perlu diperiksa lebih besar dari 5% dari total jumlah baris.

Mari kita berhitung. 5% dari 10 baris adalah 0,5 baris. Bahkan jika jumlah baris yang dibutuhkan untuk menemukan data Anda adalah 1, itu lebih besar dari 0,5. Berdasarkan jumlah baris yang lebih rendah dan aturan indeks yang baru saja saya sebutkan, Pengoptimal Permintaan MySQL akan selalu melakukan pemindaian tabel.

Karena kolom dataitu sendiri diindeks, bukannya pemindaian tabel, mysql dilakukan pemindaian indeks.

Jika Anda mengetahui dengan pasti bahwa tabel uji tidak akan pernah tumbuh, Anda dapat menghapus semua indeks dan membiarkan pemindaian tabel terjadi. Variabel status penangan harus berhenti bertambah.


Hai, terima kasih atas jawabannya. Saya telah mencoba dengan menghapus indeks dan memeriksa nilainya dengan mengeksekusi query. Tetapi nilai Handler_read_rnd_next bertambah dengan 18 yang bertambah 7 dengan indeks. Tabel yang saya sebutkan tidak diperbaiki. Itu adalah contoh, saya memasukkan 70 baris lagi ke dalam tabel, jadi total baris adalah 80 dan mengeksekusi permintaan yang sama dengan indeks pada kolom 'data' yang masih mengembalikan hanya satu baris. Tapi tetap saja ketika saya memeriksa nilai 'Handler_read_rnd_next', itu masih bertambah dengan 7. Bisakah saya tahu alasan bagaimana bendera ini bertambah dan bagaimana cara membatasi ini.
Phanindra

Alasan yang persis sama yang saya berikan masih berlaku. Pemindaian indeks dilakukan. Kali ini, indeks lengkap tidak diperlukan. Terbukti, 7 node daun dalam BTREE indeks harus dilalui untuk mendapatkan satu baris. Penghitung status penangan mengungkapkan penggunaan indeks. Satu-satunya cara untuk membatasi adalah menghapus indeks sama sekali seperti yang saya nyatakan. Kalau tidak, ini perilaku yang selalu diharapkan. Pengindeksan yang lebih baik dari struktur tabel yang lebih kompleks dan permintaan yang dirancang dengan baik dapat mengurangi penghitungan handler tetapi tidak pernah dapat menghapusnya sepenuhnya.
RolandoMySQLDBA

"Sebagai aturan praktis, Pengoptimal Permintaan MySQL akan mengabaikan penggunaan indeks jika jumlah baris yang perlu diperiksa lebih besar dari 5% dari total jumlah baris." - ini sangat sangat membantu untuk mengetahui. Apakah ada dokumentasi resmi yang mendukung ini? Terima kasih banyak!
itoctopus

2

Apa versi MySQL?

Alasan mengapa tanda ini bertambah adalah paling baik didokumentasikan di sini: http://www.mysqlperformanceblog.com/2010/06/15/what-does-handler_read_rnd-mean/

Singkatnya, ini hanyalah penghitung jumlah baris yang diambil secara berurutan selama pemindaian tabel penuh atau sebagian.

Sekarang, yang mengatakan, saya mendapatkan hasil yang berbeda:

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)

0

Jika ada indeks unik / utama pada kolom "data" maka Anda sudah melakukan optimasi untuk permintaan ini. Saya tidak dapat berpikir optimasi lebih lanjut dapat dilakukan untuk ini.

Anda juga dapat memverifikasi apakah ada FULL TABLE SCAN telah dilakukan atau belum?

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

Pastikan select_scan tidak meningkatkan nilainya, dengan cara ini Anda dapat memeriksa apakah FULL TABLE SCAN selesai atau tidak, Anda harus mencoba mengoptimalkan kueri yang tidak akan melakukan FULL TABLE SCAN.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.