MySQL 5.7以後怎麼檢視索引使用情況?
MySQL 5.7以後怎麼檢視索引使用情況?
- 通過show status like '%Handler_read%'方法檢視:整體的
[email protected] [sysbench_testdata]>show status like '%Handler_read%'; +-----------------------+---------+ | Variable_name | Value | +-----------------------+---------+ | Handler_read_first | 7 | | Handler_read_key | 29 | | Handler_read_last | 0 | | Handler_read_next | 8446377 | | Handler_read_prev | 0 | | Handler_read_rnd | 20 | | Handler_read_rnd_next | 8344612 | +-----------------------+---------+ 7 rows in set (0.00 sec)
Handler_read_key這個值代表了一個行將索引值讀的次數,很低的值表明增加索引得到的效能改善不高,因為索引並不經常使用。
Handler_read_rnd_next 的值高則查詢低效,並且應該建立索引補救。這個值是指在資料檔案中讀下一行的請求數。如果正進行大量的表掃描,Handler_read_rnd_next的值較高,則通常說明表索引不正確或查詢沒有利用索引
2.檢視具體某一個sql的索引使用情況 :
[email protected] [sysbench_testdata]>explain select k from sbtest2 where k=432 limit 2; +----+-------------+---------+------------+------+---------------+------+---------+-------+--------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+---------+------------+------+---------------+------+---------+-------+--------+----------+-------------+ | 1 | SIMPLE | sbtest2 | NULL | ref | k_2 | k_2 | 4 | const | 110944 | 100.00 | Using index | +----+-------------+---------+------------+------+---------------+------+---------+-------+--------+----------+-------------+ 1 row in set, 1 warning (0.00 sec)
欄位說明:
Type:告訴我們對錶所使用的訪問方式,主要包含如下集中型別;
◇ all:全表掃描
◇ const:讀常量,且最多隻會有一條記錄匹配,由於是常量,所以實際上只需要讀一次;
◇ eq_ref:最多隻會有一條匹配結果,一般是通過主鍵或者唯一鍵索引來訪問;
◇ fulltext:
◇ index:全索引掃描;
◇ index_merge:查詢中同時使用兩個(或更多)索引,然後對索引結果進行merge 之後再讀取表資料;
◇ index_subquery:子查詢中的返回結果欄位組合是一個索引(或索引組合),但不是一個主鍵或者唯一索引;
◇ rang:索引範圍掃描;
◇ ref:Join 語句中被驅動表索引引用查詢;
◇ ref_or_null:與ref 的唯一區別就是在使用索引引用查詢之外再增加一個空值的查詢;
◇ system:系統表,表中只有一行資料;
◇ unique_subquery:子查詢中的返回結果欄位組合是主鍵或者唯一約束;
possible_keys:可能可以利用的索引的名字。這裡的索引名字是建立索引時指定的索引暱稱;如果索引沒有暱稱,則預設顯示的是索引中第一個列的名字(在本例中,它是“firstname”)。預設索引名字的含義往往不是很明顯。
key:它顯示了MySQL實際使用的索引的名字。如果它為空(或NULL),則MySQL不使用索引。
key_len:索引中被使用部分的長度,以位元組計
ref:列出是通過常量(const),還是某個表的某個欄位(如果是join)來過濾(通過key)
的;
rows:MySQL所認為的它在找到正確的結果之前必須掃描的記錄數。顯然,這裡最理想的數字就是1。
3.通過performance_schema可以查詢到.檢視sbtest2表索引情況的查詢語句:
[email protected] [sysbench_testdata]>select object_type,object_schema,object_name,index_name,count_star,count_read,COUNT_FETCH from performance_schema.table_io_waits_summary_by_index_usage where object_name='sbtest2';
- 具體檢視過程:
[email protected] [sysbench_testdata]>select object_type,object_schema,object_name,index_name,count_star,count_read,COUNT_FETCH from performance_schema.table_io_waits_summary_by_index_usage where object_name='sbtest2';
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 1697669
Current database: sysbench_testdata
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| object_type | object_schema | object_name | index_name | count_star | count_read | COUNT_FETCH |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| TABLE | sysbench_testdata | sbtest2 | PRIMARY | 0 | 0 | 0 |
| TABLE | sysbench_testdata | sbtest2 | k_2 | 76287298 | 76287298 | 76287298 |
| TABLE | sysbench_testdata | sbtest2 | NULL | 8344631 | 8344631 | 8344631 |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
3 rows in set (0.00 sec)
[email protected] [sysbench_testdata]>select k from sbtest2 where k=432 limit 2;
+-----+
| k |
+-----+
| 432 |
| 432 |
+-----+
2 rows in set (0.00 sec)
[email protected] [sysbench_testdata]>select object_type,object_schema,object_name,index_name,count_star,count_read,COUNT_FETCH from performance_schema.table_io_waits_summary_by_index_usage where object_name='sbtest2';
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| object_type | object_schema | object_name | index_name | count_star | count_read | COUNT_FETCH |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| TABLE | sysbench_testdata | sbtest2 | PRIMARY | 0 | 0 | 0 |
| TABLE | sysbench_testdata | sbtest2 | k_2 | 76287300 | 76287300 | 76287300 |
| TABLE | sysbench_testdata | sbtest2 | NULL | 8344631 | 8344631 | 8344631 |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
3 rows in set (0.01 sec)
[email protected] [sysbench_testdata]>select k from sbtest2 where id=432 limit 2;
+-------+
| k |
+-------+
| 49866 |
+-------+
1 row in set (0.00 sec)
[email protected] [sysbench_testdata]>select object_type,object_schema,object_name,index_name,count_star,count_read,COUNT_FETCH from performance_schema.table_io_waits_summary_by_index_usage where object_name='sbtest2';
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| object_type | object_schema | object_name | index_name | count_star | count_read | COUNT_FETCH |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| TABLE | sysbench_testdata | sbtest2 | PRIMARY | 1 | 1 | 1 |
| TABLE | sysbench_testdata | sbtest2 | k_2 | 76287300 | 76287300 | 76287300 |
| TABLE | sysbench_testdata | sbtest2 | NULL | 8344631 | 8344631 | 8344631 |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
3 rows in set (0.00 sec)
[email protected] [sysbench_testdata]>