Biến trạng thái MySQL Handler_read_rnd_next đang phát triển rất nhiều

Trong trạng thái MYSQL, giá trị Handler_read_rnd_next rất cao.

Tôi biết rằng, giá trị này sẽ được tăng lên khi một truy vấn được thực thi mà không có chỉ mục thích hợp.

Nhưng, ngay cả khi chúng tôi thực thi trạng thái hiển thị như 'Handler_read_rnd_next', giá trị này vẫn tăng lên 2.

Dựa trên cờ trạng thái này, chúng tôi đang theo dõi một số thống kê.

Vì vậy, mỗi lần, số liệu thống kê này đang hiển thị quan trọng.

Chúng ta có thể loại trừ các số thực thi 'hiển thị' này khỏi số đếm 'Handler_read_rnd_next' không.

Thêm một ví dụ cho điều này,

Có một bảng có 10 hàng, bảng được lập chỉ mục trên cột 'dữ liệu' và nếu chúng tôi thực hiện truy vấn sau:

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

và nếu chúng tôi kiểm tra giá trị của 'Handler_read_rnd_next', nó sẽ tăng thêm 7.

Sau đây là kết quả của lệnh giải thích cho truy vấn trên:

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'

Có cách nào để hạn chế giá trị này không, hoặc tôi có thể biết tại sao giá trị này đang tăng lên rất nhanh.

Trước hết, chúng ta hãy xem định nghĩa của Handler_read_rnd_next.

Theo Tài liệu MySQL trên Handler_read_rnd_next:

Số lượng yêu cầu đọc hàng tiếp theo trong tệp dữ liệu. Giá trị này cao nếu bạn đang thực hiện nhiều lần quét bảng. Nói chung, điều này cho thấy các bảng của bạn không được lập chỉ mục chính xác hoặc các truy vấn của bạn không được viết để tận dụng các chỉ mục bạn có.

Bây giờ, hãy xem truy vấn của bạn:

select data from test where data = 'vwx';

Bạn nói rằng bảng có 10 hàng. Theo nguyên tắc thông thường, Trình tối ưu hóa truy vấn MySQL sẽ bỏ qua việc sử dụng chỉ mục nếu số lượng hàng cần kiểm tra lớn hơn 5% tổng số hàng.

Hãy để chúng tôi làm toán. 5% của 10 hàng là 0,5 hàng. Ngay cả khi số lượng hàng cần xác định vị trí dữ liệu của bạn là 1, con số đó lớn hơn 0,5. Dựa trên số lượng hàng thấp hơn và quy tắc chỉ mục mà tôi vừa đề cập, Trình tối ưu hóa truy vấn MySQL sẽ luôn thực hiện quét bảng.

Vì cột datađược lập chỉ mục, thay vì quét bảng, mysql đã được thực hiện quét chỉ mục.

Nếu bạn biết chắc chắn rằng bảng thử nghiệm sẽ không bao giờ phát triển, bạn có thể xóa tất cả các chỉ mục và để quét bảng xảy ra. Các biến trạng thái xử lý nên dừng tăng.

Phiên bản nào của MySQL?

Những lý do tại sao cờ này được tăng lên được ghi lại tốt nhất ở đây: http://www.mysqlperformanceblog.com/2010/06/15/what-does-handler_read_rnd-mean/

Nói tóm lại, nó chỉ là bộ đếm số lượng hàng được tìm nạp theo thứ tự trong quá trình quét toàn bộ hoặc một phần bảng.

Bây giờ, điều đó nói rằng, tôi đang nhận được một kết quả khác:

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)

Nếu có một chỉ mục duy nhất / chính trên cột "dữ liệu" thì bạn đã thực hiện tối ưu hóa cho truy vấn này. Tôi không thể nghĩ tối ưu hóa thêm có thể được thực hiện trên này.

Ngoài ra, bạn có thể xác minh xem đã có FULL TABLE SCAN hay chưa?

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

Hãy chắc chắn rằng select_scan không tăng giá trị của nó, bằng cách này, bạn có thể kiểm tra xem FULL TABLE SCAN đã được thực hiện hay chưa, Bạn nên cố gắng tối ưu hóa một truy vấn sẽ không thực hiện FULL TABLE SCAN.