接着上篇不是！你不会还不明白MySQL的EXPLAIN用法吧！
我们继续讲解！MySQL的EXPLAIN剩下的用法，
也可以看看我往期的文章
女朋友说没找到好用的画ER图工具，于是我们自己手搓了一个！🚀🚀🚀
9. rows ☆
# 9. rows：预估的需要读取的记录条数
# `值越小越好`
# 通常与filtered 一起使用
EXPLAIN SELECT * FROM s1 WHERE key1 > 'z';
rows 值越小，代表，数据越有可能在一个页里面，这样io就会更小。
10. filtered
越大越好
filtered 的值指返回结果的行占需要读到的行(rows 列的值)的百分比。
自己的理解： 比如读了100 rows. filtered 是10% 那么就说明还要对着100条进行过滤。。。。。。。。。这个是自己意淫的完全没有根据，只能先这么理解了。
如果使用的是索引执行的单表扫描，那么计算时需要估计出满足除使用到对应索引的搜索条件外的其他搜索条件的记录有多少条。
EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND common_field = 'a';
对于单表查询来说，这个filtered列的值没什么意义，我们更关注在连接查询中驱动表对应的执行计划记录的filtered值，它决定了被驱动表要执行的次数(即：rows * filtered)
EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key1 WHERE s1.common_field = 'a';
11. Extra ☆
顾名思义，Extra列是用来说明一些额外信息的，包含不适合在其他列中显示但十分重要的额外信息。我们可以通过这些额外信息来更准确的理解MySQL到底将如何执行给定的查询语句。MySQL提供的额外信息有好几十个，一下捡重点介绍
-
No tables used当查询语句的没有FROM子句时将会提示该额外信息，比如:
mysql> EXPLAIN SELECT 1;
Impossible WHERE
查询语句的WHERE子句永远为FALSE时将会提示该额外信息
mysql> EXPLAIN SELECT * FROM s1 WHERE 1 != 1;
-
Using where
当我们使用全表扫描来执行对某个表的查询，并且该语句的
WHERE子句中有针对该表的搜索条件时，在Extra列中会提示上述额外信息。
EXPLAIN SELECT * FROM s1 WHERE common_field = 'a';
当条件除了索引，还有其他条件，也会是这个提示
#当使用索引访问来执行对某个表的查询，并且该语句的`WHERE`子句中
#有除了该索引包含的列之外的其他搜索条件时，在`Extra`列中也会提示上述额外信息。
explain SELECT * FROM s1 WHERE key1 = 'fUhcQU' and common_field = 'uDHCOnalcF';
No matching min/max row
当查询列表处有MIN或者MAX聚合函数，但是并没有符合WHERE子句中的搜索条件的记录时，将会提示该额外信息
# 数据库不存在 QLjKYOx
EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'QLjKYOx';
# 数据库存在 QLjKYO
EXPLAIN SELECT MIN(key1) FROM s1 WHERE key1 = 'QLjKYO';
Using index
当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用覆盖索引的情况下，在Extra列将会提示该额外信息。
比方说下边这个查询中只需要用到idx_key1而不需要回表操作：
EXPLAIN SELECT key1 FROM s1 WHERE key1 = 'a';
-
Using index condition有些搜索条件中虽然出现了索引列，但却不能使用到索引看课件理解索引条件下推
SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%a'; mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key1 LIKE '%a';步骤1. 这里key1 > 'z' 走了索引，查出了378条数据。。。
步骤2. key1 LIKE '%b'; 这个条件依然是 key1 索引，，，所以接下来只要在遍历这378个索引。哪些符合 '%a'
步骤3. 通过步骤2 过滤出了有效 索引。。 这就是Using index condition 。
步骤4. 把符合条件的索引，进行回表查询。
完整的说明：
其中的
key1 > 'z'可以使用到索引，但是key1 LIKE '%a '却无法使用到索引，在以前版本的MySQL中，是按照下边步骤来执行这个查询的:- 先根据key1 > 'z'这个条件，从二级索引
idx_key1中获取到对应的二级索引记录。 - 根据上一步骤得到的二级索引记录中的主键值进行回表，找到完整的用户记录再检测该记录是否符合
key1 LIKE '%a'这个条件，将符合条件的记录加入到最后的结果集。
但是虽然
key1 LIKE ‘%a'不能组成范围区间参与range访问方法的执行，但这个条件毕竟只涉及到了key1列，所以MySQL把上边的步骤改进了一下:- 先根据
key1 > 'z'这个条件，定位到二级索引idx_key1中对应的二级索引记录。 - 对于指定的二级索引记录，先不着急回表，而是先检测一下该记录是否满足
key1 LIKE ‘%a'这个条件，如果这个条件不满足，则该二级索引记录压根儿就没必要回表。 - 对于满足
key1 LIKE '%a'这个条件的二级索引记录执行回表操作。
我们说回表操作其实是一个随机IO，比较耗时，所以上述修改虽然只改进了一点点，但是可以省去好多回表操作的成本。MySQL把他们的这个改进称之为
索引条件下推(英文名: Index Condition Pushdown )。如果在查询语句的执行过程中将要使用索引条件下推这个特性，在Extra列中将会显示Using index condition - 先根据key1 > 'z'这个条件，从二级索引
-
Using join buffer (Block Nested Loop)没有索引的字段进行表关联。
在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为其分配一块名叫
join buffer的内存块来加快查询速度，也就是我们所讲的基于块的嵌套循环算法mysql> EXPLAIN SELECT * FROM s1 INNER JOIN s2 ON s1.common_field = s2.common_field;
-
Not exists当我们使用左（外）连接时，如果
WHERE子句中包含要求被驱动表的某个列等于NULL值的搜索条件，而且那个列又是不允许存储NULL值的，那么在该表的执行计划的Extra列就会提示Not exists额外信息EXPLAIN SELECT * FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE s2.id IS NULL; # 都表关联了，，关联字段怎么会等于 is null
-
Using intersect(...) 、 Using union(...) 和 Using sort_union(...)-
如果执行计划的
Extra列出现了Using intersect(...)提示，说明准备使用Intersect索引 -
合并的方式执行查询，括号中的
...表示需要进行索引合并的索引名称； -
如果出现了
Using union(...)提示，说明准备使用Union索引合并的方式执行查询； -
出现了
Using sort_union(...)提示，说明准备使用Sort-Union索引合并的方式执行查询。EXPLAIN SELECT * FROM s1 WHERE key1 = 'a' OR key3 = 'a';
-
-
Zero limit -
Using filesort有一些情况下对结果集中的记录进行排序是可以使用到索引的，比如下边这个查询:
EXPLAIN SELECT * FROM s1 ORDER BY key1 LIMIT 10;这个查询语句可以利用
idx_key1索引直接取出key1列的10条记录，然后再进行回表操作就好了。但是很多情况下排序操作无法使用到索引，只能在内存中(记录较少的时候）或者磁盘中(记录较多的时候）进行排序，MySQL把这种在内存中或者磁盘上进行排序的方式统称为文件排序（英文名:filesort)。如果某个查询需要使用文件排序的方式执行查询，就会在执行计划的Extra列中显示Using filesort提示EXPLAIN SELECT * FROM s1 ORDER BY common_field LIMIT 10; -
Using temporary在许多查询的执行过程中，MySQL可能会借助临时表来完成一些功能，比如去重、排序之类的，比如我们在执行许多包含
DISTINCT、GROUP BY、UNION等子句的查询过程中，如果不能有效利用索引来完成查询，MySQL很有可能寻求通过建立内部的临时表来执行查询。如果查询中使用到了内部的临时表，在执行计划的Extra列将会显示Using temporary提示EXPLAIN SELECT DISTINCT common_field FROM s1;#执行计划中出现`Using temporary`并不是一个好的征兆，因为建立与维护临时表要付出很大成本的，所以 #我们`最好能使用索引来替代掉使用临时表`。比如：扫描指定的索引idx_key1即可 EXPLAIN SELECT key1, COUNT(*) AS amount FROM s1 GROUP BY key1;
12. 小结
- EXPLAIN不考虑各种Cache
- EXPLAIN不能显示MySQL在执行查询时所作的优化工作
- EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况
- 部分统计信息是估算的，并非精确值
2. EXPLAIN的进一步使用
2.1 EXPLAIN四种输出格式
这里谈谈EXPLAIN的输出格式。EXPLAIN可以输出四种格式： 传统格式 ， JSON格式 ， TREE格式 以及 可 视化输出 。用户可以根据需要选择适用于自己的格式。
1. 传统格式
传统格式简单明了，输出是一个表格形式，概要说明查询计划。
mysql> EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE
s2.common_field IS NOT NULL;
+----+-------------+-------+------------+------+---------------+-------
| id | select_type | table | partitions | type | possible_keys | key
+----+-------------+-------+------------+------+---------------+-------
| 1 | SIMPLE | s2 | NULL | ALL | idx_key1 | NULL
| 1 | SIMPLE | s1 | NULL | ref | idx_key1 | idx_ke
+----+-------------+-------+------------+------+---------------+-------
2 rows in set, 1 warning (0.00 sec)
2. JSON格式
第1种格式中介绍的EXPLAIN语句输出中缺少了一个衡量执行计划好坏的重要属性——成本。而JSON格式是四种格式里面输出信息最详尽的格式，里面包含了执行的成本信息。
-
JSON格式：在EXPLAIN单词和真正的查询语句中间加上
FORMAT=JSON。EXPLAIN FORMAT=JSON SELECT .... -
EXPLAIN的Column与JSON的对应关系:(来源于MySQL 5.7文档)
这样我们就可以得到一个json格式的执行计划，里面包含该计划花费的成本，比如这样:
mysql> EXPLAIN FORMAT=JSON SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = 'a' \G
*************************** 1. row ***************************
EXPLAIN: {
"query_block": {
"select_id": 1,
"cost_info": {
"query_cost": "1360.07"
},
"nested_loop": [
{
"table": {
"table_name": "s1",
"access_type": "ALL",
"possible_keys": [
"idx_key1"
],
"rows_examined_per_scan": 9895,
"rows_produced_per_join": 989,
"filtered": "10.00",
"cost_info": {
"read_cost": "914.80",
"eval_cost": "98.95",
"prefix_cost": "1013.75",
"data_read_per_join": "1M"
},
"used_columns": [
"id",
"key1",
"key2",
"key3",
"key_part1",
"key_part2",
"key_part3",
"common_field"
],
"attached_condition": "((`atguigudb1`.`s1`.`common_field` = 'a') and (`atguigudb1`.`s1`.`key1` is not null))"
}
},
{
"table": {
"table_name": "s2",
"access_type": "eq_ref",
"possible_keys": [
"idx_key2"
],
"key": "idx_key2",
"used_key_parts": [
"key2"
],
"key_length": "5",
"ref": [
"atguigudb1.s1.key1"
],
"rows_examined_per_scan": 1,
"rows_produced_per_join": 989,
"filtered": "100.00",
"index_condition": "(cast(`atguigudb1`.`s1`.`key1` as double) = cast(`atguigudb1`.`s2`.`key2` as double))",
"cost_info": {
"read_cost": "247.38",
"eval_cost": "98.95",
"prefix_cost": "1360.08",
"data_read_per_join": "1M"
},
"used_columns": [
"id",
"key1",
"key2",
"key3",
"key_part1",
"key_part2",
"key_part3",
"common_field"
]
}
}
]
}
}
1 row in set, 2 warnings (0.01 sec)
我们使用 # 后边跟随注释的形式为大家解释了 EXPLAIN FORMAT=JSON 语句的输出内容，但是大家可能 有疑问 "cost_info" 里边的成本看着怪怪的，它们是怎么计算出来的？先看 s1 表的 "cost_info" 部 分：
"cost_info": {
"read_cost": "914.80",
"eval_cost": "98.95",
"prefix_cost": "1013.75",
"data_read_per_join": "1M"
}
-
read_cost是由下边这两部分组成的：-
IO 成本
-
检测
rows × (1 - filter)条记录的 CPU 成本
小贴士： rows和filter都是我们前边介绍执行计划的输出列，在JSON格式的执行计划中，rows相当于rows_examined_per_scan，filtered名称不变。
-
-
eval_cost是这样计算的检测
rows × filter条记录的成本。 -
prefix_cost就是单独查询s1表的成本，也就是：read_cost + eval_cost -
data_read_per_join表示在此次查询中需要读取的数据量。
对于 s2 表的 "cost_info" 部分是这样的：
"cost_info": {
"read_cost": "247.38",
"eval_cost": "98.95",
"prefix_cost": "1360.08",
"data_read_per_join": "1M"
}
由于 s2 表是被驱动表，所以可能被读取多次，这里的 read_cost 和 eval_cost 是访问多次 s2 表后累 加起来的值，大家主要关注里边儿的 prefix_cost 的值代表的是整个连接查询预计的成本，也就是单 次查询 s1 表和多次查询 s2 表后的成本的和，也就是 :
247.38 + 98.95 + 1013.75 = 1360.08
3. TREE格式
TREE格式是8.0.16版本之后引入的新格式，主要根据查询的 各个部分之间的关系 和 各部分的执行顺序 来描 述如何查询
mysql> EXPLAIN FORMAT=tree SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE s1.common_field = 'a'\G
*************************** 1. row ***************************
EXPLAIN: -> Nested loop inner join (cost=1360.08 rows=990)
-> Filter: ((s1.common_field = 'a') and (s1.key1 is not null)) (cost=1013.75 rows=990)
-> Table scan on s1 (cost=1013.75 rows=9895)
-> Single-row index lookup on s2 using idx_key2 (key2=s1.key1), with index condition: (cast(s1.key1 as double) = cast(s2.key2 as double)) (cost=0.25 rows=1)
1 row in set, 1 warning (0.00 sec)
4. 可视化输出
可视化输出，可以通过MySQL Workbench可视化查看MySQL的执行计划。通过点击Workbench的放大镜图 标，即可生成可视化的查询计划。
上图按从左到右的连接顺序显示表。红色框表示 全表扫描 ，而绿色框表示使用 索引查找 。对于每个表， 显示使用的索引。还要注意的是，每个表格的框上方是每个表访问所发现的行数的估计值以及访问该表 的成本。
2.2 SHOW WARNINGS的使用
mysql> EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE
s2.common_field IS NOT NULL;
使用完explain 后紧接着使用 SHOW WARNINGS \G
mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Note
Code: 1003
Message: /* select#1 */ select `atguigudb1`.`s1`.`key1` AS `key1`,`atguigudb1`.`s2`.`key1` AS `key1` from `atguigudb1`.`s1` join `atguigudb1`.`s2` where ((`atguigudb1`.`s1`.`key1` = `atguigudb1`.`s2`.`key1`) and (`atguigudb1`.`s2`.`common_field` is not null))
1 row in set (0.00 sec)
可以看到查询优化器真正执行的语句
粘出来并不一定可以运行
大家可以看到SHOW WARNINGS展示出来的信息有三个字段，分别是Level、Code、Message。我们最常见的 就是Code为1003的信息，当Code值为1003时,Message字段展示的信息类似于查询优化器将我们的查询语句重写后的语句。比如我们上边的查询本来是一个左(外)连接查询，但是有一个s2.common_field IS NOT NULL的条件，这就会导致查询优化器把左(外）连接查询优化为内连接查询，从 SHOW WARNINGS的Message字段也可以看出来，原本的LEFT JOIN已经变成了JOIN(内连接)。
3. 分析优化器执行计划：trace
OPTIMIZER_TRACE 是MySQL 5.6引入的一项跟踪功能，它可以跟踪优化器做出的各种决策(比如访问表的方法、各种开销计算、各种转换等)，并将跟踪结果记录到INFORMATION_SCHEMA.OPTIMIZER_TRACE表中。
此功能默认关闭。开启trace，并设置格式为JSON，同时设置trace最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整展示。
SET optimizer_trace="enabled=on",end_markers_in_json=on;
set optimizer_trace_max_mem_size=1000000;
开启后，可分析如下语句：
- SELECT
- INSERT
- REPLACE
- UPDATE
- DELETE
- EXPLAIN
- SET
- DECLARE
- CASE
- IF
- RETURN
- CALL
测试：执行如下SQL语句
select * from student where id < 10;
最后， 查询 information_schema.optimizer_trace 就可以知道MySQL是如何执行SQL的 :
select * from information_schema.optimizer_trace\G
mysql> select * from information_schema.optimizer_trace\G
*************************** 1. row ***************************
# //第1部分：查询语句
QUERY: select * from student where id < 10
//第2部分：QUERY字段对应语句的跟踪信息
TRACE: {
"steps": [
{
"join_preparation": { /*预备工作*/
"select#": 1,
"steps": [
{
"expanded_query": "/* select#1 */ select `student`.`id` AS `id`,`student`.`stuno` AS `stuno`,`student`.`name` AS `name`,`student`.`age` AS `age`,`student`.`classId` AS `classId` from `student` where (`student`.`id` < 10)"
}
] /* steps */
} /* join_preparation */
},
{
"join_optimization": {/*进行优化*/
"select#": 1,
"steps": [
{
"condition_processing": {/*条件处理*/
"condition": "WHERE",
"original_condition": "(`student`.`id` < 10)",
"steps": [
{
"transformation": "equality_propagation",
"resulting_condition": "(`student`.`id` < 10)"
},
{
"transformation": "constant_propagation",
"resulting_condition": "(`student`.`id` < 10)"
},
{
"transformation": "trivial_condition_removal",
"resulting_condition": "(`student`.`id` < 10)"
}
] /* steps */
} /* condition_processing */
},
{
"substitute_generated_columns": {/*替换生成的列*/
} /* substitute_generated_columns */
},
{
"table_dependencies": [ /* 表的依赖关系*/
{
"table": "`student`",
"row_may_be_null": false,
"map_bit": 0,
"depends_on_map_bits": [
] /* depends_on_map_bits */
}
] /* table_dependencies */
},
{
"ref_optimizer_key_uses": [ /* 使用键*/
] /* ref_optimizer_key_uses */
},
{
"rows_estimation": [ /*行判断*/
{
"table": "`student`",
"range_analysis": {
"table_scan": {
"rows": 3945207,
"cost": 404306
} /* table_scan */,/*表扫描*/
"potential_range_indexes": [
{
"index": "PRIMARY",
"usable": true,
"key_parts": [
"id"
] /* key_parts */
}
] /* potential_range_indexes */,
"setup_range_conditions": [
] /* 设置条件范围 */,
"group_index_range": {
"chosen": false,
"cause": "not_group_by_or_distinct"
} /* group_index_range */,
"skip_scan_range": {
"potential_skip_scan_indexes": [
{
"index": "PRIMARY",
"usable": false,
"cause": "query_references_nonkey_column"
}
] /* potential_skip_scan_indexes */
} /* skip_scan_range */,
"analyzing_range_alternatives": {/*分析范围选项*/
"range_scan_alternatives": [
{
"index": "PRIMARY",
"ranges": [
"id < 10"
] /* ranges */,
"index_dives_for_eq_ranges": true,
"rowid_ordered": true,
"using_mrr": false,
"index_only": false,
"in_memory": 0.159895,
"rows": 9,
"cost": 1.79883,
"chosen": true
}
] /* range_scan_alternatives */,
"analyzing_roworder_intersect": {
"usable": false,
"cause": "too_few_roworder_scans"
} /* analyzing_roworder_intersect */
} /* analyzing_range_alternatives */,
"chosen_range_access_summary": {/*选择范围访问摘要*/
"range_access_plan": {
"type": "range_scan",
"index": "PRIMARY",
"rows": 9,
"ranges": [
"id < 10"
] /* ranges */
} /* range_access_plan */,
"rows_for_plan": 9,
"cost_for_plan": 1.79883,
"chosen": true
} /* chosen_range_access_summary */
} /* range_analysis */
}
] /* rows_estimation */
},
{
"considered_execution_plans": [/*考虑执行计划*/
{
"plan_prefix": [
] /* plan_prefix */,
"table": "`student`",
"best_access_path": {/*最佳访问路径*/
"considered_access_paths": [
{
"rows_to_scan": 9,
"access_type": "range",
"range_details": {
"used_index": "PRIMARY"
} /* range_details */,
"resulting_rows": 9,
"cost": 2.69883,
"chosen": true
}
] /* considered_access_paths */
} /* best_access_path */,
"condition_filtering_pct": 100, /*行过滤百分比*/
"rows_for_plan": 9,
"cost_for_plan": 2.69883,
"chosen": true
}
] /* considered_execution_plans */
},
{
"attaching_conditions_to_tables": { /*将条件附加到表上*/
"original_condition": "(`student`.`id` < 10)",
"attached_conditions_computation": [
] /* attached_conditions_computation */,
"attached_conditions_summary": [ /*附加条件概要*/
{
"table": "`student`",
"attached": "(`student`.`id` < 10)"
}
] /* attached_conditions_summary */
} /* attaching_conditions_to_tables */
},
{
"finalizing_table_conditions": [
{
"table": "`student`",
"original_table_condition": "(`student`.`id` < 10)",
"final_table_condition ": "(`student`.`id` < 10)"
}
] /* finalizing_table_conditions */
},
{
"refine_plan": [ /*精简计划*/
{
"table": "`student`"
}
] /* refine_plan */
}
] /* steps */
} /* join_optimization */
},
{
"join_execution": { /*执行*/
"select#": 1,
"steps": [
] /* steps */
} /* join_execution */
}
] /* steps */
}
/
/*第3部分：跟踪信息过长时，被截断的跟踪信息的字节数。*/
MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0 /*丢失的超出最大容量的字节*/
/*第4部分：执行跟踪语句的用户是否有查看对象的权限。当不具有权限时，该列信息为1且TRACE字段为空，一般在
调用带有SQL SECURITY DEFINER的视图或者是存储过程的情况下，会出现此问题。*/
INSUFFICIENT_PRIVILEGES: 0 /*缺失权限*/
1 row in set (0.01 sec)
3. MySQL监控分析视图-sys schema
3.1 Sys schema视图摘要
1. 主机相关：以host_summary开头，主要汇总了IO延迟的信息。
2. Innodb相关：以innodb开头，汇总了innodb buffer信息和事务等待innodb锁的信息。
3. I/o相关：以io开头，汇总了等待I/O、I/O使用量情况。
4.内存使用情况：以memory开头，从主机、线程、事件等角度展示内存的使用情况
5.连接与会话信息：processlist和session相关视图，总结了会话相关信息。
6. 表相关：以schema_table开头的视图，展示了表的统计信息。
7. 索引信息：统计了索引的使用情况，包含冗余索引和未使用的索引情况。
8.语句相关：以statement开头，包含执行全表扫描、使用临时表、排序等的语句信息。
9. 用户相关：以user开头的视图，统计了用户使用的文件I/O、执行语句统计信息。
10.等待事件相关信息：以wait开头，展示等待事件的延迟情况。
3.2 Sys schema视图使用场景
索引情况
#1. 查询冗余索引
select * from sys.schema_redundant_indexes;
#2. 查询未使用过的索引
select * from sys.schema_unused_indexes;
#3. 查询索引的使用情况
select index_name,rows_selected,rows_inserted,rows_updated,rows_deleted
from sys.schema_index_statistics where table_schema='dbname' ;
表相关
# 1. 查询表的访问量
select table_schema,table_name,sum(io_read_requests+io_write_requests) as io from
sys.schema_table_statistics group by table_schema,table_name order by io desc;
# 2. 查询占用bufferpool较多的表
select object_schema,object_name,allocated,data
from sys.innodb_buffer_stats_by_table order by allocated limit 10;
# 3. 查看表的全表扫描情况
select * from sys.statements_with_full_table_scans where db='dbname';
语句相关
#1. 监控SQL执行的频率
select db,exec_count,query from sys.statement_analysis
order by exec_count desc;
#2. 监控使用了排序的SQL
select db,exec_count,first_seen,last_seen,query
from sys.statements_with_sorting limit 1;
#3. 监控使用了临时表或者磁盘临时表的SQL
select db,exec_count,tmp_tables,tmp_disk_tables,query
from sys.statement_analysis where tmp_tables>0 or tmp_disk_tables >0
order by (tmp_tables+tmp_disk_tables) desc;
IO 相关
#1. 查看消耗磁盘IO的文件
select file,avg_read,avg_write,avg_read+avg_write as avg_io
from sys.io_global_by_file_by_bytes order by avg_read limit 10;
Innodb 相关
#1. 行锁阻塞情况
select * from sys.innodb_lock_waits;
风险提示:
通过sys库去查询时，MySQL会消耗大量资源去收集相关信息，严重的可能会导致业务请求被阻塞，从而引起故障。建议生产上
不要频繁的去查询sys或者performance_schema、information_schema来完成监控、巡检等工作。
交流学习
最后，如果这篇文章对你有所启发，请帮忙转发给更多的朋友，让更多人受益！如果你有任何疑问或想法，欢迎随时留言与我讨论，我们一起学习、共同进步。别忘了关注我，我将持续分享更多有趣且实用的技术文章，期待与你的交流！
