分析SQL瓶颈，SQL耗时

原文链接：https://www.cnblogs.com/yidengjiagou/p/16587437.html

1. 查看Profile配置

show variables like '%profil%';

have_profiling 表示是否支持profile功能，YES表示支持

profiling 表示是否开启profile功能，ON开启，OFF关闭，默认是关闭状态

profiling_history_size 表示保存最近15条历史数据

2. 开启Profile功能

set profiling=1;

注意：修改配置，只对当前会话生效，会话关闭，Profile历史信息被清空。

3. 使用Profile

先造点数据，创建一张用户表：

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `name` varchar(100) NOT NULL DEFAULT '' COMMENT '姓名',
  `age` tinyint NOT NULL  DEFAULT 0 NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

执行一条耗时SQL：

select * from user order by name;

下面轮到主角Profile出场了。

我们执行的所有SQL语句都会被记录到Profile里面，包括执行失败的SQL语句。

可以使用show profiles命令查看：

输出参数详解：

Query_ID 表示自动分配的查询ID，顺序递增。

Duration 表示SQL语句执行耗时

Query 表示SQL语句内容

然后，我们再使用Query_ID去Profile中查看具体每一步的耗时情况：

show profile for query 1;

可以清楚的看到耗时主要花在创建排序索引（Creating sort index）上面。

再试一条SQL：

select distinct name from user;

这次的耗时主要花在了，创建临时文件、拷贝文件到磁盘、发送数据、删除临时表上面。

由此，可以得知distinct函数会创建临时文件，提醒我们建索引。

我们还可以扩展一下这条分析语句，查看一下cpu和block io的使用情况：

show profile cpu,block io for query 2;

另外，其实所有Profile历史数据都被记录在information_schema.profiling表中，我们也可以查询表得到结果：

select * from information_schema.profiling where Query_ID=2;

以上数据都是基于MySQL5.7版本，在MySQL8.0版本的输出结果字段有些变化。