目录
- profiling
- explain
profiling
MySQL Profile 可以用来收集关于查询性能的信息，以便进行性能优化。MySQL 查询 Profile 可以告诉你每个查询花费了多长时间，使用了多少资源，执行了哪些操作等
profiling默认时关闭，使用以下命令开启profiling。
mysql> SET profiling = 1;
然后可以使用 SHOW PROFILES;命令来查看sql执行耗时。会展示一个列表，其中包含每个查询的 ID、执行时间和内存使用情况。
mysql> show profiles;
+———-+————+———————–+
| Query_ID | Duration | Query |
+———-+————+———————–+
| 1 | 0.00014600 | SELECT DATABASE() |
| 2 | 0.00035250 | select * from account |
+———-+————+———————–+
如果要查看某个sql的详细信息，可以使用
SHOW PROFILE FOR QUERY 查询的Id;查询的ID就是 SHOW PROFILES展示的列表对应的第一列的值。
mysql> show profile for query 2;
+——————————–+———-+
| Status | Duration |
+——————————–+———-+
| starting | 0.000059 |
| Executing hook on transaction | 0.000005 |
| starting | 0.000009 |
| checking permissions | 0.000007 |
| Opening tables | 0.000127 |
| init | 0.000006 |
| System lock | 0.000009 |
| optimizing | 0.000004 |
| statistics | 0.000015 |
| preparing | 0.000021 |
| executing | 0.000042 |
| end | 0.000004 |
| query end | 0.000003 |
| waiting for handler commit | 0.000008 |
| closing tables | 0.000007 |
| freeing items | 0.000010 |
| cleaning up | 0.000018 |
在高版本的mysql中，profilling也被提示过时了，被移到performance_schema下一些表中，具体可以看官方介绍
https://dev.mysql.com/doc/refman/8.0/en/performance-schema-query-profiling.html
explain
可以使用explain select语句来查看语句的具体执行计划。它可以显示 MySQL 查询优化器是如何决定执行查询的。通过执行计划，你可以了解到 MySQL 是如何选择索引、连接表以及访问行的顺序的。explain展示的计划结果列表会有以下列信息。
mysql> explain SELECT * FROM test WHERE id =10;
+—-+————-+——-+——-+—————+———+———+——-+——+——-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——-+—————+———+———+——-+——+——-+
| 1 | SIMPLE | test | const | PRIMARY | PRIMARY | 4 | const | 1 | NULL |
+—-+————-+——-+——-+—————+———+———+——-+——+——-+
来看下具体每列大概意思
1、id
表示查询中执行的顺序，id相同从上到下按顺序执行，一般id越大优先级越高。如果有子查询，则子查询会有不同的 id。子查询会先执行。
2、select_type
SIMPLE：简单查询，没有使用子查询或连表操作
PRIMARY：复杂查询中最外层查询
UNION: union后面的查询
SUBQUERY: 子查询
DERIVED: from引用的子查询
MATERIALIZED： 物化子查询
例1：
explain SELECT * FROM web_shop_order o inner join web_user u on o.uid=u.uid;
两个都是简单查询：SIMPLE
例2：
EXPLAIN SELECT u.uid,u.username,t.nums FROM web_user u INNER JOIN
(SELECT uid,COUNT(1) AS nums FROM web_order2 GROUP BY uid) t ON u.uid=t.uid
最外层的查询就是：PRIMARY
分组子查询是：DERIVED
例3：
EXPLAIN SELECT 1 UNION SELECT 2;
会有三条执行计划信息，第一个查询是：PRIMARY，第二个查询是UNION，最后的结果集是UNION RESULT。
3、table列
表名
4、type
表访问关联类型
- system
表只有一行，是下面const类型的一种特殊情况
const
表中最多只有一行记录匹配，这种就是在where条件中使用主键等值查询
mysql> explain SELECT * FROM web_user where uid=100;±—±————±———±——±————–±——–±——–±——±—–±——+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |±—±————±———±——±————–±——–±——–±——±—–±——+| 1 | SIMPLE | web_user | const | PRIMARY | PRIMARY | 4 | const | 1 | NULL |±—±————±———±——±————–±——–±——–±——±—–±——+
- eq_ref
等值关联。对于来自前一个表的每个行组合，从这个表中读取一行。除了system和const类型之外，这是最好的连接类型。当连接使用索引的所有部分，并且索引是PRIMARY KEY或UNIQUE NOT NULL索引时，使用它。
mysql> explain SELECT * FROM web_shop_order o ,web_user u WHERE o.uid=u.uid;
+—-+————-+——-+——–+—————+———+———+————–+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——-+——–+—————+———+———+————–+——+————-+
| 1 | SIMPLE | o | ALL | NULL | NULL | NULL | NULL | 8 | Using where |
| 1 | SIMPLE | u | eq_ref | PRIMARY | PRIMARY | 4 | db_xjy.o.uid | 1 | Using where |
+—-+————-+——-+——–+—————+———+———+————–+——+————-+
- ref
普通索引查找。非唯一所有。可能会返回多行。
mysql> explain SELECT * FROM web_user WHERE username=\’张三\’;
+—-+————-+———-+——+—————+———-+———+——-+——+———————–+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+———-+——+—————+———-+———+——-+——+———————–+
| 1 | SIMPLE | web_user | ref | username | username | 63 | const | 1 | Using index condition |
+—-+————-+———-+——+—————+———-+———+——-+——+———————–+
- range
索引范围扫描，在一个索引列上进行特定范围进行查找。如in、between and、like、大于或小于等这种。
普通索引也使用。后面的key列对应的使用的索引列。
mysql> explain select * from web_user where uid in(100,101);
+—-+————-+———-+——-+—————+———+———+——+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+———-+——-+—————+———+———+——+——+————-+
| 1 | SIMPLE | web_user | range | PRIMARY | PRIMARY | 4 | NULL | 2 | Using where |
+—-+————-+———-+——-+—————+———+———+——+——+————-+
1 row in set (0.00 sec)
mysql> explain select * from web_user where username like \’曹%\’;
+—-+————-+———-+——-+—————+———-+———+——+——+———————–+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+———-+——-+—————+———-+———+——+——+———————–+
| 1 | SIMPLE | web_user | range | username | username | 63 | NULL | 9 | Using index condition |
+—-+————-+———-+——-+—————+———-+———+——+——+———————–+
1 row in set (0.00 sec)
- index
index类型。一般在联合索引情况下会使用到。分两种情况：
1、如果判断可以使用索引进行条件过滤，走对应索引。Extra列会显示Using index。
2、索引无法覆盖所有查询条件，则走全表扫描。
- ALL
全表扫描。没什么好说的。没有走索引。
5、possible_keys
可能使用的索引名称。
6、index
实际使用的索引。如果没有选择使用索引，这一列值为null。有时候肯能possible_keys有值，index为NUll可能数据库任务走索引不如全表扫描快。
7、key_len
使用的索引长度。一个索引可能左值匹配使用了部分，也可能是联合索引使用了其中的一部分。
8、ref
这一列显示了哪些字段或者常量被用来和key列对应索引匹配从表中查询数据。
像前面的等值匹配就是常量，连表就是对应的join列。
9、rows
预估扫描行数
10、filtered
符合查询条件的数据百分比
11、Extra
mysql是如何执行该查询的额外的信息。前面说的这些列已经不能完全表名了。就像前面在说type列为index时，如果使用索引会在Extra有Using index信息。
几个常见例子：
Using index：使用索引
Using temporary：使用临时表。一般需要优化
Using filesort：使用外部排序，排序字段不是索引列
Using where： 条件过滤
还有很多，可以查看官方文档https://dev.mysql.com/doc/refman/8.0/en/explain-output.html#explain-extra-information。
到此这篇关于mysql 使用profiling和explain来分析查询语句性能的文章就介绍到这了,更多相关mysql 使用profiling和explain内容请搜索悠久资源网以前的文章或继续浏览下面的相关文章希望大家以后多多支持悠久资源网！
