共计 3087 个字符，预计需要花费 8 分钟才能阅读完成。
留神：应用数据库可视化工具 Navicat 查问进去的参数居然跟间接 xshell 查出来的参数不一样，Navicat 的版本是11.2.7-premium，所以批改参数还是在命令行批改，比拟精确。show profiles命令是在 MySQL5.0 当前才新退出的，是一个语句剖析的利器。
如何应用
首先查看是否反对该性能。
show variables like ‘have_profiling’;
+----------------+-------+
| Variable_name | Value |
+----------------+-------+
| have_profiling | YES |
+----------------+-------+默认是敞开的，开启该性能。
set profiling=on;
查看开启状态。15 示意历史缓存 sql 的个数。
show variables like ‘profiling%’;
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| profiling | ON |
| profiling_history_size | 15 |
+------------------------+-------+接下来轻易运行几条 sql，并应用 show profiles 命令，将展现方才运行的 SQL 语句。参数很好了解，不做解释了。
+----------+------------+----------------------------------+
| Query_ID | Duration | Query |
+----------+------------+----------------------------------+
| 1 | 0.00106200 | show variables like 'profiling%' |
| 2 | 0.00044400 | select * from t_logs |
| 3 | 0.00019350 | select * from t_commonts |
| 4 | 0.00043725 | select * from t_comments |
+----------+------------+----------------------------------+上面剖析指定的 SQL 语句，应用如下命令(4 是下面查出来的 Query_ID，cpu 和 block io 代表 cpu 的解决工夫和 io 的工夫)：
如果 cpu 工夫慢，示意 cpu 的占用率比拟高，io 慢的话，示意内存占用率比拟高。
show profile cpu,block io for query 4;
+----------------------+----------+----------+------------+--------------+---------------+
| Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+----------------------+----------+----------+------------+--------------+---------------+
| starting | 0.000072 | 0.000032 | 0.000033 | 0 | 0 |
| checking permissions | 0.000008 | 0.000003 | 0.000004 | 0 | 0 |
| Opening tables | 0.000022 | 0.000011 | 0.000011 | 0 | 0 |
| init | 0.000038 | 0.000038 | 0.000000 | 0 | 0 |
| System lock | 0.000009 | 0.000009 | 0.000000 | 0 | 0 |
| optimizing | 0.000005 | 0.000005 | 0.000000 | 0 | 0 |
| statistics | 0.000014 | 0.000014 | 0.000000 | 0 | 0 |
| preparing | 0.000011 | 0.000010 | 0.000000 | 0 | 0 |
| executing | 0.000003 | 0.000003 | 0.000000 | 0 | 0 |
| Sending data | 0.000209 | 0.000209 | 0.000000 | 0 | 0 |
| end | 0.000004 | 0.000004 | 0.000000 | 0 | 0 |
| query end | 0.000007 | 0.000006 | 0.000000 | 0 | 0 |
| closing tables | 0.000009 | 0.000009 | 0.000000 | 0 | 0 |
| freeing items | 0.000017 | 0.000017 | 0.000000 | 0 | 0 |
| cleaning up | 0.000011 | 0.000011 | 0.000000 | 0 | 0 |
+----------------------+----------+----------+------------+--------------+---------------+其中 cpu 和 block io 两个参数比拟重要，还有其余参数，如下：
| type | desc |
|---|---|
| ALL | 显示所有的开销信息 |
| BLOCK IO | 显示与 IO 相干的开销 |
| CONTEXT SWITCHES | 上下文切换相干开销 |
| CPU | 与 CPU 相干的开销 |
| IPC | 显示发送和承受相干的开销信息 |
| MEMORY | 显示内存相干的开销信息 |
| PAGE FAULTS | 显示页面谬误相干开销信息 |
| SOURCE | 显示和 Source_function，SOURCE_file，SOURCE_line 相干的开销信息 |
| SWAPS | 显示替换次数相干的开销信息 |
参数的剖析
在 show profile 的时候有一个字段叫 status，几个重要的参数如下：
| 状态 | 形容 |
|---|---|
| System lock | 确认是因为哪个锁引起的，通常是因为 MySQL 或 InnoDB 内核级 的锁引起的倡议：如果耗时较大再关注即可，个别状况下都还好 |
| Sending data | 从 server 端发送数据到客户端，也有可能是接管存储引擎层返回的数据 再发送给客户端，数据量很大时尤其常常能看见， 备注：Sending Data 不是网络发送，是从硬盘读取，发送到网络是 Writing to net。倡议：通过索引或加上 LIMIT，缩小须要扫描并且发送 给客户端的数据量 |
| Sorting result | 正在对后果进行排序，相似 Creating sort index，不过是失常表， 而不是在内存表中进行排序倡议：创立适当的索引 |
| Table lock | 表级锁，没什么好说的，要么是因为 MyISAM 引擎表级锁， 要么是其余状况显式锁表 |
| create sort index | 以后的 SELECT 中须要用到长期表在进行 ORDER BY 排序。 倡议：创立适当的索引 |
| checking query cache for querychecking privileges on cachedsending cached result to clienstoring result in query cache |
和 query cache 相干的状态，曾经屡次强烈建议敞开 |
除了上述几个字段，如果 Status 呈现了如下几个字段，阐明 SQL 性能问题很重大。
- converting HEAP to MyISAM：查问后果太大，内存不够用，往磁盘上存储了。
- Creating tmp table：创立长期表，首先拷贝原有数据到长期表，用完后再删除长期表，在数据量很大的状况下，异样的耗性能。
- Copying to tmp table on disk：把内存中的长期表复制到磁盘，也相当的消耗性能。
- locked：锁表了。