Because I do a lot of Performance Tuning gigs I get often in contact with these status variables. In the beginning I had a problem to understand them and now I have a problem to memorize the relation of the name and the meaning. Therefore I wrote this little summary:

PREPARE THE EXAMPLE

To show you the effect I have worked out a little example:

CREATE TABLE test (

    id    INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY

  , data  VARCHAR(32)

  , ts    TIMESTAMP

  , INDEX (data)

);

INSERT INTO test

VALUES (NULL, 'abc', NOW()), (NULL, 'abc', NOW()), (NULL, 'abd', NOW())

     , (NULL, 'acd', NOW()), (NULL, 'def', NOW()), (NULL, 'pqr', NOW())

     , (NULL, 'stu', NOW()), (NULL, 'vwx', NOW()), (NULL, 'yza', NOW())

     , (NULL, 'def', NOW())

;

SELECT * FROM test;

+----+------+---------------------+

| id | data | ts                  |

+----+------+---------------------+

|  1 | abc  | 2008-01-18 16:28:40 |

|  2 | abc  | 2008-01-18 16:28:40 |

|  3 | abd  | 2008-01-18 16:28:40 |

|  4 | acd  | 2008-01-18 16:28:40 |

|  5 | def  | 2008-01-18 16:28:40 |

|  6 | pqr  | 2008-01-18 16:28:40 |

|  7 | stu  | 2008-01-18 16:28:40 |

|  8 | vwx  | 2008-01-18 16:28:40 |

|  9 | yza  | 2008-01-18 16:28:40 |

| 10 | def  | 2008-01-18 16:28:40 |

+----+------+---------------------+

To see the effect of a query do the following steps:

  1. FLUSH STATUS;
  2. Execute the query
  3. SHOW SESSION STATUS LIKE 'handler_read%';
  4. Do an EXPLAIN of the query

HANDLER_READ_FIRST

The number of times the first entry was read from an index. If this value is high, it suggests that the server is doing a lot of full index scans.

+-------------+          +---+---+

| Table       |          | In|ex |

|             |          |   |   |

|             |          |   |   |

|             |          |   |   |

|             |          |   |   |

|             |          |   v   |

|             |          |       |

|             |          |       |

+-------------+          +-------+

SELECT data FROM test;

10 rows in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_first    | 1     |

| Handler_read_key      | 0     |

| Handler_read_next     | 10    |

+-----------------------+-------+

EXPLAIN SELECT data FROM test;

+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+

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

+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+

|  1 | SIMPLE      | test  | index | NULL          | data | 35      | NULL |   10 | Using index |

+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+

So what we can basically say is, that we had 1 full index scan and it did 10+1 index fetches.

Let us do some more examples

SELECT data FROM test WHERE data BETWEEN 'A' AND 'O';

6 rows in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_first    | 0     |

| Handler_read_key      | 1     |

| Handler_read_next     | 6     |

+-----------------------+-------+

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

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

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

|  1 | SIMPLE      | test  | range | data          | data | 35      | NULL |    5 | Using where; Using index |

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

Here it seems the query is not starting with Handler_read_first though it could theoretically. Instead of we get a Handler_read_key. What we can also see is the "wrong" estimation of the optimizer in the execution plan.

Whit this example the query really could start from the beginning...

SELECT data FROM test WHERE data < 'O';

6 rows in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_first    | 0     |

| Handler_read_key      | 1     |

| Handler_read_next     | 6     |

+-----------------------+-------+

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

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

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

|  1 | SIMPLE      | test  | range | data          | data | 35      | NULL |    5 | Using where; Using index |

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------

But it does not!

The same for this query:

SELECT data FROM test WHERE data LIKE 'a%';

4 rows in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_first    | 0     |

| Handler_read_key      | 1     |

| Handler_read_next     | 4     |

+-----------------------+-------+

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

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

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

|  1 | SIMPLE      | test  | range | data          | data | 35      | NULL |    4 | Using where; Using index |

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

And this query does something completely different:

SELECT data FROM test WHERE data IN ('abc', 'abd', 'acd');

4 rows in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_first    | 0     |

| Handler_read_key      | 3     |

| Handler_read_next     | 4     |

+-----------------------+-------+

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

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

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

|  1 | SIMPLE      | test  | range | data          | data | 35      | NULL |    4 | Using where; Using index |

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+

I was not able to get any Handler_read_first count other than by a real full index scan. So I would say that a Handler_read_first is equivalent to Number of full index scans.

A full index scan is better than a full table scan but still not good because they burn a lot of CPU cycles. But sometimes you cannot avoid it...

HANDLER_READ_KEY

The number of requests to read a row based on a key. If this value is high, it is a good indication that your tables are properly indexed for your queries.

See also the examples in the previous chapter.

+-------------+          +-------+

| Table       |          | Index |

|             | <------  |       | <--+

|             |          |       |

|             |          |       |

|             |          |       |

|             |          |       |

|             |          |       |

|             |          |       |

+-------------+          +-------+

SELECT data FROM test where data = 'abc';

2 rows in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_first    | 0     |

| Handler_read_key      | 1     |

| Handler_read_next     | 2     |

+-----------------------+-------+

+----+-------------+-------+------+---------------+------+---------+-------+------+--------------------------+

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

+----+-------------+-------+------+---------------+------+---------+-------+------+--------------------------+

|  1 | SIMPLE      | test  | ref  | data          | data | 35      | const |    2 | Using where; Using index |

+----+-------------+-------+------+---------------+------+---------+-------+------+--------------------------+

What makes me wondering in this example (an also in the previous) is, that based on the query there is IMHO no reason to access the table (row)...

SELECT * FROM test where data = 'pqr';

1 row in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_first    | 0     |

| Handler_read_key      | 1     |

| Handler_read_next     | 1     |

+-----------------------+-------+

+----+-------------+-------+------+---------------+------+---------+-------+------+-------------+

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

+----+-------------+-------+------+---------------+------+---------+-------+------+-------------+

|  1 | SIMPLE      | test  | ref  | data          | data | 35      | const |    1 | Using where |

+----+-------------+-------+------+---------------+------+---------+-------+------+-------------+

In this example it makes clearly sense...!

HANDLER_READ_NEXT

The number of requests to read the next row in key order. This value is incremented if you are querying an index column with a range constraint or if you are doing an index scan.

See also the examples in the previous chapters.

+-------------+          +-------+

| Table       |          | Index |

|             |          |       |

|             | <------  |   +   |

|             | <------  |   |   |

|             | <------  |   v   |

|             |          |       |

|             |          |       |

|             |          |       |

+-------------+          +-------+

HANDLER_READ_PREV

The number of requests to read the previous row in key order. This read method is mainly used to optimize ORDER BY ... DESC.

+-------------+          +-------+

| Table       |          | Index |

|             |          |       |

|             | <------  |   ^   |

|             | <------  |   |   |

|             | <------  |   +   |

|             |          |       |

|             |          |       |

|             |          |       |

+-------------+          +-------+

SELECT data FROM test ORDER BY data DESC;

10 rows in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_first    | 0     |

| Handler_read_key      | 0     |

| Handler_read_next     | 0     |

| Handler_read_prev     | 10    |

+-----------------------+-------+

+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+

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

+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+

|  1 | SIMPLE      | test  | index | NULL          | data | 35      | NULL |   10 | Using index |

+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+

There is no such status like Handler_read_last implemented like it could be according to the HANDLER functions [ 1 ].

SELECT * FROM test where data between 'A' and 'B' ORDER BY data DESC;

4 rows in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_first    | 0     |

| Handler_read_key      | 1     |

| Handler_read_next     | 0     |

| Handler_read_prev     | 4     |

+-----------------------+-------+

+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+

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

+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+

|  1 | SIMPLE      | test  | range | data          | data | 35      | NULL |    4 | Using where |

+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+

HANDLER_READ_RND

The number of requests to read a row based on a fixed position. This value is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan entire tables or you have joins that don't use keys properly.

This status comes into account if the old file_sort mechanism is used [ 2 ].

To make this work we have to modify slightly our table:

ALTER TABLE test ADD COLUMN file_sort text;

UPDATE test SET file_sort = 'abcdefghijklmnopqrstuvwxyz' WHERE id = 1;

UPDATE test SET file_sort = 'bcdefghijklmnopqrstuvwxyza' WHERE id = 2;

UPDATE test SET file_sort = 'cdefghijklmnopqrstuvwxyzab' WHERE id = 3;

UPDATE test SET file_sort = 'defghijklmnopqrstuvwxyzabc' WHERE id = 4;

UPDATE test SET file_sort = 'efghijklmnopqrstuvwxyzabcd' WHERE id = 5;

UPDATE test SET file_sort = 'fghijklmnopqrstuvwxyzabcde' WHERE id = 6;

UPDATE test SET file_sort = 'ghijklmnopqrstuvwxyzabcdef' WHERE id = 7;

UPDATE test SET file_sort = 'hijklmnopqrstuvwxyzabcdefg' WHERE id = 8;

UPDATE test SET file_sort = 'ijklmnopqrstuvwxyzabcdefgh' WHERE id = 9;

UPDATE test SET file_sort = 'jklmnopqrstuvwxyzabcdefghi' WHERE id = 10;
SELECT * FROM test ORDER BY file_sort asc;

10 rows in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_rnd      | 10    |

| Handler_read_rnd_next | 11    |

+-----------------------+-------+

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

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

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

|  1 | SIMPLE      | test  | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using filesort |

+----+-------------+-------+------+---------------+------+---------+------+------+----------------+

This is really a performance killer and should be avoided whenever possible!

HANDLER_READ_RND_NEXT

The number of requests to read the next row in the data file. This value is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.

+------+------+          +-------+

| Table|      |          | Index |

|      |      |          |       |

|      |      |          |       |

|      |      |          |       |

|      |      |          |       |

|      v      |          |       |

|             |          |       |

|             |          |       |

+-------------+          +-------+

SELECT * FROM test;

10 rows in set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_rnd_next | 11    |

+-----------------------+-------+

+----+-------------+-------+------+---------------+------+---------+------+------+-------+

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

+----+-------------+-------+------+---------------+------+---------+------+------+-------+

|  1 | SIMPLE      | test  | ALL  | NULL          | NULL | NULL    | NULL |   10 |       |

+----+-------------+-------+------+---------------+------+---------+------+------+-------+

Obviously also filtering does not have a impact on the work which is performed:

SELECT * FROM test WHERE ts = '2008-01-18 17:33:39';

Empty set

+-----------------------+-------+

| Variable_name         | Value |

+-----------------------+-------+

| Handler_read_rnd_next | 11    |

+-----------------------+-------+

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+

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

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+

|  1 | SIMPLE      | test  | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where |

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+

LITERATURE

  1. [ 1 ] HANDLER Syntax
  2. [ 2 ] File sort

OPEN ITEMS, MORE TO INVESTIGATE

  • What about Falcon, InnoDB, MySQL Cluster and and other Storage Engines?
  • Filesort and read_rnd_buffer_size
  • Why are all values + 1?
  • What about joins?

WHY ARE ALL VALUES + 1?

Roel Van de Paar gave me the following hint:

Values are +1 because of 'end of something' - for instance when you're reading from a data file, the server will try one more time to read the next record and this is what is being logged.

转自：http://www.fromdual.com/mysql-handler-read-status-variables

THE HANDLER_READ_* STATUS VARIABLES的更多相关文章

  1. Mysql命令show global status求根溯源

    近来,发现好多公司对mysql的性能监控是通过show global status实现的,因此对于这个命令想要探究一番,看他是否是实时更新的. 在此之前,我们必须搞明白mysql对于这个命令的执行过程 ...

  2. Show Global Status 整理

    原文来源:MySQL 5.5 Reference Manual 部分翻译取自:<MySQL_5.1中文参考手册> 转载请注明原文链接http://www.cnblogs.com/lenag ...

  3. MySQL - Show Global Status 整理

    2019独角兽企业重金招聘Python工程师标准>>> MySQL - Show Global Status 整理 原文来源:MySQL 5.5 Reference Manual 部 ...

  4. 有关binlog的那点事（mysql5.7.13）

    binlog作为mysql中最重要的日志之一,能实现异常恢复以及主从复制. 我们主要讨论的是主从复制中的binlog,这里将以mysql5.7.13的源码为主要依据来分析binlog. 在主从复制中, ...

  5. MySQL Range Optimization

    8.2.1.3 Range Optimization MYSQL的Range Optimization的目的还是尽可能的使用索引 The range access method uses a sing ...

  6. Linux 平台MySQL启动关闭方式总结

    MySQL的启动方法有很多种,下面对比.总结这几种方法的一些差异和特性,下面实验的版本为MySQL 5.6.如有疏漏或不足,敬请指点一二.   1:使用mysqld启动.关闭MySQL服务 mysql ...

  7. [MySQL Reference Manual] 8 优化

    8.优化 8.优化 8.1 优化概述 8.2 优化SQL语句 8.2.1 优化SELECT语句 8.2.1.1 SELECT语句的速度 8.2.1.2 WHERE子句优化 8.2.1.3 Range优 ...

  8. MySQL主从同步延迟

    早上接到open-falcon报警,一台mysql从库同步延迟2w多秒,mysql版本比较老,用的5.1.37. 连接从库查找原因: show processlist一下,查看哪些线程在跑. 看到Ti ...

  9. Nagios配置文件详解

    首先要看看目前Nagios的主配置路径下有哪些文件.[root@nagios etc]# ll总用量 152-rwxrwxr-x. 1 nagios nagios 1825 9月  24 14:40 ...

随机推荐

  1. 有了JSON.stringify()，处理json将变得更简单！！

    之前处理json 需要拼接json字符串,但是,如果用上JSON.stringify()的话,忘了json语法以没关系了..... @{ ViewBag.Title = "GetStr&qu ...

  2. 面试&笔试常见题，你了解多少？

    HTML:1.  什么是语义化的HTML?有何意义?为什么要做到语义化?(高频率考题)2.  行内元素和块元素分别有哪些?(高频率)3.  严格模式与混杂模式的区分?如何触发这两种模式?(高频率)4. ...

  3. php中对2个数组相加的函数

    <?php function array_add($a,$b){ //根据键名获取两个数组的交集 $arr=array_intersect_key($a, $b); //遍历第二个数组,如果键名 ...

  4. java三大框架学习总结（1）

    企业里并不一定就会用这三种框架,关键是要你能懂得面向对象的原理,以及对服务器客户端请求响应方式的理解,再加上你对缓存的利用,这才能成为真正的高手,框架就好比是一把武器,它最多是能帮你更好的杀敌,而如果 ...

  5. struts标签小记

    1.<s:iterator>标签的  奇偶数行使用不同样式 <s:iterator id="list" value="#request.listq&qu ...

  6. linux：档案与档案系统的压缩、打包与备份

    压缩比:压缩后与压缩的档案锁占用的磁碟空间大小,就称之为压缩比 压缩技术: a.将没有使用到的空间丢出去,以让档案资料占用的空间变小 b.将重复的资料统计记录(比如100个1,不是真正的用100个元位 ...

  7. 如何用Java解析CSV文件

    首先看一下csv文件的规则: csv(Comma Separate Values)文件即逗号分隔符文件,它是一种文本文件,可以直接以文本打开,以逗号分隔.windows默认用excel打开.它的格式包 ...

  8. 无向连通图求割边+缩点+LCA

    Network Time Limit: 5000MS   Memory Limit: 65536K Total Submissions: 7082   Accepted: 2555 Descripti ...

  9. override 与 overdown 的区别

    重写与重载的区别 1. 重载是方法的名称相同.参数或参数类型不同,进行多次重载以适应不同的需要       2. 重写是进行基类中函数的重写.为了适应需要.

  10. HDU 4573 Throw the Stones（动态三维凸包）（2013 ACM-ICPC长沙赛区全国邀请赛）

    题目链接:http://acm.hdu.edu.cn/showproblem.php?pid=4573 Problem Description Remember our childhood? A fe ...