开发俏皮话

【让我996不算啥，我只怕测试也996给我提bug！】

技术金字塔

本篇文章会按照自上而下以及自下而上的两种方向去“游览”【MySQL技术金字塔】，两个方向分别是从成本出发的（潜台词就是便宜越好，照顾公司成本哦！），本章内容，可能有点多，希望大家慢慢消化，实在不行来片“吗丁啉”，哈哈，开玩笑了！

技术梗概

主要技术分布为6大部分，如下图金子图所示：

image

研发成本角度

从软件的【研发成本】的角度而言：伴随着优化的方向，从金字塔顶部像金字塔底部的方向进行过度，伴随着高度越来越低，成本会越来越低，这个方向其实是非常考验技术人员与项目管理者的能力的，但是它确实，老板对象看到的，哈哈。

image

技术可行性和效果角度

从软件的【技术可行性和效果】的角度而言：伴随着优化的方向，从金字塔低部像金字塔顶部的方向进行过度，伴随着高度越来越高，成本会越来越高，耗费的财力和人力也会相对的有所降低，但是如果多花钱，老板肯定不愿意，比如，请一些行业大牛或者一些牛掰的服务器等，可以看出来正好与上面的方向相反。

image

总结一下，以上这两点的方针，遵循着研发成本的越来越低+效果方案越来越高，那么我们就划分出一个公式，作为系统服务调优方法论，我们就按照金字塔层面，进行自下而上进行调优！我们接下来就来按照这个方向进行分析。

调优白皮书

业务需求和业务架构

产品中单要支援，需求出装要全面。——王者荣耀之产品篇

调整一下合适的需求，其实是一个很不错的方案，所以如果可以从根本上去出发，进行调整需求是一个很有效果的方案哦！并且对一些不合理的需求说不！在做架构设计的时候，应该充分考虑业务实际场景，考虑好数据库的选项和引入一些其他的方案是非常重要的，例如NoSQL或者NewSQL等。所以，调整好一个一个系统架构是一个非常不错的方案。

尽量将请求拦截在系统上游传统业务系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小。
读多写少的常用多使用缓存这是一个典型的读多写少的应用场景，非常适合使用缓存。

SQL技术调优

根据业务需求，不单纯的写好SQL语句，还要对SQL语句进行调优，使得其性能变得最佳化。

调优的思路

调优主要有三个部分组成：发现问题、分析问题和解决问题。

发现问题（慢SQL的优化和分析）

发现慢SQL以及查询日志

查询慢SQL的日志是MySQL内置的一个功能，可以记录执行时间超过我们配置阈值的SQL语句。

参数与默认值：

image

使用方式-修改MySQL服务配置

一般我们就设置“老三样”即可！

修改我们安装后的配置文件my.cnf，在[mysqld]段落中加入以上参数配置：

[mysqld]
log_output='FILE,TABLE';
slow_query_log=ON // 代表开启慢sql参数进行开启
long_query_time=0.001 //查询时间（秒）

之后进行重启服务

service mysqld restart

使用方式-修改全局服务配置

set global log_output='TABLE,FILE';
set global slow_query_log = 'NO';
set long_query_time = 0.001;

这种方式，不需要重启就可以生效，但是当服务器重启的时候，又会重新丢失配置。

以上的配置可以将慢查询SQL记录到mysql数据库中的slow_log表中以及对应的slow_sql的文件中去。

分析慢SQ的查询日志

查询slow_log表，当根据上面的设置，当log_output设置为TABLE的时候，就会将mysql的慢查询日志记录到mysql.slow_log表中去，我们可以采用select * from mysql.slow_log去进行查询，可以根据此方面进行分析和统计sql的执行性能。

分析慢SQL日志文件

当log_output设置为FILE的时候，因为文件过大，不方便查看，所以可以采用专门的工具进行分析，这里主要介绍原生的mysqldumpslow工具进行分析，如下图所示：

mysqldumpslow --help：

image

使用案例：

如果要查询出返回结果行数最多的20条SQL：

mysqldumpslow -s  r -t 20 /path/show.log

根据查询时间进行排序，并且带有left join的20条SQL：

mysqldumpslow -s  t  -t  -g "left join"  /path/show.log

当然还有其他相关的MySQL慢查询分析日志工具，例如mysql profiles或者pt-query-digest也可以专门进行分析。有兴趣的小伙伴可以搜搜看。

执行计划分析慢SQL

explain关键字进行执行慢SQL语句，进行指标分析：

image

案例分析

最简单的案例就是：

explain sql语句

image

id字段

它表示代表着语句SQL中每一个部分原子查询（维护）操作的标识单位，如果explain中的有多个id对应的数据项，那么切记一定要按照：倒叙进行执行，也就是说：

数字越大的，越先执行分析
数字编号相同，从上到下进行分析

select_type字段

查询类型，如下几组值：

image

table字段

它表示当前这一行正在访问哪张表，如果SQL定义了别名，则展示表的别名

partitions字段

当前查询匹配记录的分区。对于未分区的表，返回null。

type字段

连接类型，有如下几种取值，性能从好到坏排序如下:

system：

该表只有一行(相当于系统表)，system是const类型的特例。

const:

针对主键或唯一索引的等值查询扫描, 最多只返回一行数据. const查询速度非常快, 因为它仅仅读取一次即可。

eq_ref：

当使用了索引的全部组成部分，并且索引是PRIMARY KEY或UNIQUE NOT NULL 才会使用该类型，性能仅次于system及const。

多表关联查询，单行匹配

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column=other_table.column;

多表关联查询，联合索引，多行匹配

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column_part1=other_table.column AND ref_table.key_column_part2=1;

ref

当满足索引的最左前缀规则，或者索引不是主键也不是唯一索引时才会发生。如果使用的索引只会匹配到少量的行，性能也是不错的。

根据索引(非主键，非唯一索引)，匹配到多行

SELECT * FROM ref_table WHERE key_column=expr;

多表关联查询，单个索引，多行匹配

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column=other_table.column;

多表关联查询，联合索引，多行匹配

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column_part1=other_table.column AND ref_table.key_column_part2=1;

TIPS

最左前缀原则，指的是索引按照最左优先的方式匹配索引。比如创建了一个组合索引(column1, column2, column3)，那么，如果查询条件是:

WHERE column1 = 1、WHERE column1= 1 AND column2 = 2、WHERE column1= 1 AND column2 = 2 AND column3 = 3 都可以使用该索引;
WHERE column2 = 2、WHERE column2 = 1 AND column3 = 3就无法匹配该索引。

fulltext：全文索引

ref_or_null

该类型类似于ref，但是MySQL会额外搜索哪些行包含了NULL。这种类型常⻅于解析子查询。

SELECT * FROM ref_table WHERE key_column=expr OR key_column IS NULL;

index_merge

此类型表示使用了索引合并优化，表示一个查询里面用到了多个索引。

unique_subquery

该类型和eq_ref类似，但是使用了IN查询，且子查询是主键或者唯一索引。例如:

 value in ( select primary_key from single_table where some_condition)

index_subquery

 value in ( select key_column  from single_table where some_condition)

和unique_subquery类似，只是子查询使用的是非唯一索引

range

范围扫描，表示检索了指定范围的行，主要用于有限制的索引扫描。比较常⻅的范围扫描是带有 BETWEEN子句或WHERE子句里有>、>=、<、<=、IS NULL、<=>、BETWEEN、LIKE、IN()等操作符。

SELECT * FROM tbl_name
WHERE key_column BETWEEN 10 and 20;
SELECT * FROM tbl_name
WHERE key_column IN (10,20,30);

index

全索引扫描，和ALL类似，只不过index是全盘扫描了索引的数据。当查询仅使用索引中的一部分列时，可使用此类型。有两种场景会触发:

如果索引是查询的覆盖索引，并且索引查询的数据就可以满足查询中所需的所有数据，则只扫描索引树。此时，explain的Extra 列的结果是Using index。index通常比ALL快，因为索引的大小通常小于表数据。
按索引的顺序来查找数据行，执行了全表扫描。此时，explain的Extra列的结果不会出现Uses index。

ALL

全表扫描，性能最差。

possible_keys

展示当前查询可以使用哪些索引，这一列的数据是在优化过程的早期创建的，因此有些索引可能对于后续优化过程是没用的。

key

表示MySQL实际选择的索引

key_len

索引使用的字节数。由于存储格式，当字段允许为NULL时，key_len比不允许为空时大1字节。

key_len计算公式

可以参考博客： https://www.cnblogs.com/gomysql/p/4004244.html

ref

表示将哪个字段或常量和key列所使用的字段进行比较。如果ref是一个函数，则使用的值是函数的结果。要想查看是哪个函数，可在EXPLAIN语句之后紧跟一个SHOW WARNING语句。

rows

MySQL估算SQL执行后会扫描的行数，数值越小越好。

filtered

符合查询条件的数据百分比，最大100。用rows × filtered可获得和下一张表连接的行数。例如rows = 1000， filtered = 50%，则和下一张表连接的行数是500。

TIPS

在MySQL 5.7之前，想要显示此字段需使用explain extended命令; MySQL.5.7及更高版本，explain默认就会展示filtered

Extra(重点分析)

展示有关本次查询的附加信息，取值如下:

Child of 'table' pushed join@1

此值只会在NDB Cluster下出现。

const row not found

查询语句SELECT ... FROM tbl_name，而表是空的

Deleting all rows

对于DELETE语句，某些引擎(例如MyISAM)支持以一种简单而快速的方式删除所有的数据，如果使用了这种优化，则显示此值.

Distinct

查找distinct值，当找到第一个匹配的行后，将停止为当前行组合搜索更多行
FirstMatch(tbl_name)当前使用了半连接FirstMatch策略.

Full scan on NULL key

子查询中的一种优化方式，在无法通过索引访问null值的时候使用

Impossible HAVING

HAVING子句始终为false，不会命中任何行

Impossible WHERE

WHERE子句始终为false，不会命中任何行

Impossible WHERE noticed after reading const tables

MySQL已经读取了所有const(或system)表，并发现WHERE子句始终为false
LooseScan(m..n)当前使用了半连接LooseScan策略，

No matching min/max row

没有任何能满足例如 SELECT MIN(...) FROM ... WHERE condition 中的condition的行

160

no matching row in const table

对于关联查询，存在一个空表，或者没有行能够满足唯一索引条件

No matching rows after partition pruning

对于DELETE或UPDATE语句，优化器在partition pruning(分区修剪)之后，找不到要delete或update的内容

No tables used

当此查询没有FROM子句或拥有FROM DUAL子句时出现。例如:explain select 1

Not exists

MySQL能对LEFT JOIN优化，在找到符合LEFT JOIN的行后，不会为上一行组合中检查此表中的更多行。例如:

 SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id WHERE t2.id IS NULL;

MySQL8以前的版本会这么分析：

例如，t2.id定义成了 NOT NULL ，此时，MySQL会扫描t1，并使用t1.id的值查找t2中的行。如果MySQL在t2中找到一个匹配的行，它会知道t2.id永远不会为NULL，并且不会扫描t2中具有相同id值的其余行。也就是说，对于t1中的每一行，MySQL只需要在t2中只执行一次查找，而不考虑在t2中实际匹配的行数。

MySQL 8.0.17及更高版本中：

如果出现此提示，还可表示形如 NOT IN (subquery) 或 NOT EXISTS (subquery) 的WHERE条件已经在内部转换为反连接。
这将删除子查询并将其表放入最顶层的查询计划中，从而改进查询的开销。通过合并半连接和反联接，优化器可以更加自由地对执行计划中的表重新排序，在某些情况下，可让查询提速。

可以通过在EXPLAIN语句后紧跟一个SHOW WARNING语句，并分析结果中Message列，从而查看何时对该查询执行了反联接转换。

反连接：两表关联只返回主表的数据，并且只返回主表与子表没关联上的数据，这种的连接方式。

Plan isn't ready yet

使用了EXPLAIN FOR CONNECTION，当优化器尚未完成为在指定连接中为执行的语句创建执行计划时，就会出现此值。

Range checked for each record (index map: N)
- MySQL没有找到合适的索引去使用，但是去检查是否可以使用range或index_merge来检索行时，会出现此提示。
- index map N索引的编号从1开始，按照与表的SHOW INDEX所示相同的顺序。索引映射值N是指示哪些索引是候选的位掩码值。例如0x19(二进制11001)的值意味着将考虑索引1、4和5。

好了看到这里你是否会觉得已经眼花缭乱了？现在开始重头戏，上面的可以作为知识扩展和了解，但下面的内容建议你一定要理解哦，会对性能优化有很大的帮助哦！

unique row not found

对于形如 SELECT ... FROM tbl_name 的查询，但没有行能够满足唯一索引或主键查询的条件。

Using filesort（重点）
- 出现的原因：当SQL查询中包含 ORDER BY子句的操作后，而且无法利用索引完成排序操作的时候，MySQL Query Optimizer 不得不选择相应的排序算法来实现。
- 数据较少时从内存排序，当超过Memory_Sort的阈值的时候就会从磁盘排序，性能超级低哦！
- 并且，Explain命令并不会显示的告诉MySQL数据库客户端用哪种排序。

官方解释：MySQL需要额外的一次传递，以找出如何按排序顺序检索行。

通过根据联接类型浏览所有行，并为所有匹配WHERE子句的行保存排序关键字和行的指针来完成排序。
然后关键字被排序，并按排序顺序检索行。

Using index（重点）
- (俗称：单覆盖索引哦！)，仅使用索引树中的信息从表中检索列信息，而不必进行其他查找以读取实际行。
- 当查询仅使用属于单个索引的列时，可以使用此策略。例如:
```
 select id from table
```
Using index condition（重点）
- (俗称：覆盖下推哦！)，表示先按条件过滤索引，过滤完索引后找到所有符合索引条件的数据行，随后用 WHERE 子句中的其他条件去过滤这些数据行。通过这种方式，除非有必要，否则索引信息将可以延迟“下推”读取整个行的数据。例如:
```
SELECT * FROM people where id > 10 and age = 10 or address > 100000 ;
```

可以通过开关进行调整开或者关闭索引条件下推

 SET optimizer_switch = 'index_condition_pushdown=off';
 SET optimizer_switch = 'index_condition_pushdown=on';

多说一句，MySQL分成了Server层和Engine层，下推指的是将请求交给引擎层处理，相比较而言性能差异有不同的引擎决定。

Using index for group-by（次重点）

数据访问和 Using index 一样，所需数据只须要读取索引，当Query 中使用GROUP BY或DISTINCT 子句时，如果分组字段也在索引中，Extra中的信息就会是 Using index for group-by，例如：

explain SELECT name FROM t1 group by name

Using index for skip scan（不是特别重要，记住它算是SQL索引其效果了）

表示使用了Skip Scan。底层采用了“Skip Scan Range Access Method算法机制”，意思说是提前做出了索引查询定位，并且减少了很多的扫描，其实和using Index区别不大！

Using join buffer (Block Nested Loop)，不是特别重要，表示采用了嵌套子查询的缓存批次处理技术！

Using join buffer 使用Block Nested Loop或Batched Key Access算法提高join的性能，此部分属于采用了Batched Key Access（批次关键字进行检索），意思是不会再进行一行一行对比，而是进行一批一批的方式进行比较，并且他们的内存行类似相邻的位置，所以采用buffer缓存快的机制缓存这一批次对比检索的数据，大大提高了效率！

具体有兴趣的小伙伴可以推荐参考： https://www.cnblogs.com/chenpingzhao/p/6720531.html

Using MRR

使用了Multi-Range Read优化策略。详⻅ “Multi-Range Read Optimization”
Using sort_union(...), Using union(...), Using intersect(...)，这些指示索引扫描如何合并为index_merge连接类型。详⻅参考官方的“Index Merge Optimization” 。

Using temporary（非常重要）

上面说了当出现排序或者分组的时候数据需要进行进一步的计算，此时无法利用索引那天然的数据模型来解决的时候该咋办!为了解决该查询，MySQL需要创建一个临时表来保存结果。如果查询包含不同列的GROUP BY和 ORDER BY子句，通常会发生这种情况。

name字段有索引
- explain SELECT name FROM t1 group by name
name无索引
- explain SELECT name FROM t1 group by name。
Using where（比较重要）

如果我们不是读取表的所有数据，或者不是仅仅通过索引就可以获取所有需要的数据，则会出现using where信息。阈值相对应的就是“覆盖索引哦”！

SELECT * FROM t1 where id = 1

Zero limit

该查询有一个limit 0子句，不能选择任何行。

explain SELECT name FROM resource_template limit 0

Explain的命令讲解

EXPLAIN可产生额外的扩展信息，可通过在EXPLAIN语句后紧跟一条SHOW WARNING语句查看扩展信息。

在MySQL 8.0.12及更高版本，扩展信息可用于SELECT、DELETE、INSERT、REPLACE、UPDATE语句;
在MySQL 8.0.12之前，扩展信息仅适用于SELECT语句;
在MySQL 5.6及更低版本，需使用EXPLAIN EXTENDED xxx语句;而从MySQL 5.7开始，无需添加 EXTENDED关键词。

SHOW WARNING的结果并不一定是一个有效SQL，也不一定能够执行(因为里面包含了很多特殊标记)

特殊取值含义介绍

：自动生成的临时表key。
(expr)：表达式(例如标量子查询)执行了一次，并且将值保存在了内存中以备以后使用。对于包括多个值的结果，可能会创建临时表，你将会看到的字样。
(query fragment)：子查询被转换为 EXISTS，性能会变得更加好。
(query fragment)：这是一个内部优化器对象，对用户没有任何意义
(query fragment)：使用索引查找来处理查询片段，从而找到合格的行
(condition, expr1, expr2)：如果条件是true，则取expr1，否则取expr2
(expr)：验证表达式不为NULL的测试
(query fragment)：使用子查询实现
materialized-subquery.col_name，在内部物化临时表中对col_name的引用，以保存子查询的结果
(query fragment)：使用主键来处理查询片段，从而找到合格的行
(expr)：这是一个内部优化器对象，对用户没有任何意义
/* select#N */ select_stmt：SELECT与非扩展的EXPLAIN输出中id=N的那行关联
outer_tables semi join (inner_tables)：半连接操作。
：表示创建了内部临时表而缓存中间结果

估计查询性能

多数情况下，你可以通过计算磁盘的搜索次数来估算查询性能。对于比较小的表，通常可以在一次磁盘搜索中找到行 (因为索引可能已经被缓存了)，而对于更大的表，你可以使用B-tree索引进行估算:你需要进行多少次查找才能找到行: log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1
在MySQL中，index_block_length通常是1024字节，数据指针一般是4字节。比方说，有一个500,000的表，key是3字节，那么根据计算公式 log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 次搜索。
该索引将需要500,000 7 3/2 = 5.2MB的存储空间(假设典型的索引缓存的填充率是2/3)，因此你可以在内存中存放更多索引，可能只要一到两个调用就可以找到想要的行了。
但是，对于写操作，你需要四个搜索请求来查找在何处放置新的索引值，然后通常需要2次搜索来更新索引并写入行。
前面的讨论并不意味着你的应用性能会因为log N而缓慢下降。只要内容被OS或MySQL服务器缓存，随着表的变大，只会稍微变慢。在数据量变得太大而无法缓存后，将会变慢很多，直到你的应用程序受到磁盘搜索约束(按照log N增⻓)。为了避免这种情况，可以根据数据的增⻓而增加key的。对于MyISAM表，key的缓存大小由名为key_buffer_size 的系统变量控制，详⻅ Section 5.1.1, “Configuring the Server”

SQL性能分析

SQL性能分析的手段我们主要介绍一下三种：

SHOW PROFILE
INFORMATION_SCHEMA.PROFILING
PERFORMANCE_SCHEMA

SHOW PROFILE（旧版本的MySQL服务可使用,新版本已废弃）

SHOW PROFILE是MySQL的一个性能分析命令，可以跟踪SQL各种资源消耗。使用格式如下:

SHOW PROFILE [type [, type] ... ] [FOR QUERY n]
[LIMIT row_count [OFFSET offset]]

type的选值范围：
- ALL：显示所有信息
- BLOCK IO：显示阻塞的输入输出次数
- CONTEXT SWITCHES：显示自愿及非自愿的上下文切换次数
- CPU：显示用户与系统CPU使用时间
- IPC：显示消息发送与接收的次数
- MEMORY：显示内存相关的开销，目前未实现此功能
- PAGE FAULTS：显示⻚错误相关开销信息
- SOURCE：列出相应操作对应的函数名及其在源码中的位置(行)
- SWAPS：显示swap交换次数

默认情况下，SHOW PROFILE只展示Status和Duration两列，如果想展示更多信息，可指定type，使用步骤如下:

查看是否支持SHOW PROFILE功能，yes标志支持。从MySQL 5.0.37开始，MySQL支持SHOW PROFILE。

select @@have_profiling;

查看当前是否启用了SHOW PROFILE，0表示未启用，1表示已启用

select @@profiling;

设置为当前会话开启或关闭性能分析，设成1表示开启，0表示关闭

set profiling=1

为最近发送的SQL语句做一个概要的性能分析。展示的条目数目由 profiling_history_size会话变量控制，该变量的默认值为15。最大值为100。将值设置为0具有禁用分析的实际效果。
Show profiles 命令

-- 默认展示15条 
show profiles
-- 使用profiling_history_size调整展示的条目数
set profiling_history_size = 100;

首先使用show profiles分析指定查询:

image

使用show profile进行分析，默认情况下，只展示Status和Duration两列，如果想展示更多信息，可指定type。

image

使用SHOW PROFILE FOR QUERY 1;，1代表的query_id(show profiles)

image

展示CPU相关的开销

image

分析完成后，记得关闭掉SHOW PROFILE功能:

set profiling = 1

NFORMATION_SCHEMA.PROFILING

INFORMATION_SCHEMA.PROFILING用来做性能分析，它的内容对应SHOW PROFILE和SHOW PROFILES 语句产生的信息。除非设置了 set profiling = 1; ，否则该表不会有任何数据。

该表包括以下字段:

QUERY_ID:语句的唯一标识
SEQ:一个序号，展示具有相同QUERY_ID值的行的显示顺序
STATE:分析状态
DURATION:在这个状态下持续了多久(秒)
CPU_USER，CPU_SYSTEM:用户和系统CPU使用情况(秒)
CONTEXT_VOLUNTARY，CONTEXT_INVOLUNTARY:发生了多少自愿和非自愿的上下文转换
BLOCK_OPS_IN，BLOCK_OPS_OUT:块输入和输出操作的数量
MESSAGES_SENT，MESSAGES_RECEIVED:发送和接收的消息数 PAGE_FAULTS_MAJOR，PAGE_FAULTS_MINOR:主要和次要的⻚错误信息
SWAPS:发生了多少SWAP SOURCE_FUNCTION，SOURCE_FILE，SOURCE_LINE:当前状态是在源码的哪里执行的

SHOW PROFILE本质上使用的也是INFORMATION_SCHEMA.PROFILING表;

INFORMATION_SCHEMA.PROFILING表已被废弃，在未来可能会被删除。未来将可使用Performance Schema替代，

采用show profile方式进行查询

SHOW PROFILE FOR QUERY 2;

INFORMATION_SCHEMA.PROFILING的查询方式

SELECT STATE, FORMAT(DURATION, 6) AS DURATION FROM INFORMATION_SCHEMA.PROFILING
WHERE QUERY_ID = 2 ORDER BY SEQ;

PERFORMANCE_SCHEMA(未来的继承者)

PERFORMANCE_SCHEMA是MySQL建议的性能分析方式，未来SHOW PROFILE/PROFILES、 INFORMATION_SCHEMA.PROFILING都会废弃。

PERFORMANCE_SCHEMA在MySQL 5.6引入，因此，在MySQL 5.6及更高版本才能使用。可使用 SHOW VARIABLES LIKE 'performance_schema';

 SHOW VARIABLES LIKE 'performance_schema';

下面来用PERFORMANCE_SCHEMA去实现SHOW PROFILE类似的效果: 查看是否开启性能监控

image

查看启用情况，MySQL 5.7开始默认启用。

你也可以执行类似如下的SQL语句，只监控指定用户执行的SQL:

image

这样，就只会监控localhost机器上test_user用户发送过来的SQL。其他主机、其他用户发过来的SQL统统不监控，执行如下SQL语句，开启相关监控项:

image

使用开启监控的用户，执行SQL语句，比如:

image

执行如下SQL，获得语句的EVENT_ID。

image

这一步类似于 SHOW PROFILES。执行如下SQL语句做性能分析，这样就可以知道这条语句各种阶段的信息了。

image

MySQL官方文档声明SHOW PROFILE已被废弃，并建议使用Performance Schema作为替代品。

三种方式对比与选择

SHOW PROFILE:简单、方便，已废弃
INFORMATION_SCHEMA.PROFILING，它和SHOW PROFILE本质一样
PERFORMANCE_SCHEMA:未来之光，但目前来说使用不够方便

因此:目前可以继续用SHOW PROFILE了解PERFORMANCE_SCHEMA，为未来做好准备

OPTIMIZER_TRACE相关参数

optimizer_trace总开关，默认值: enabled=off,one_line=off enabled:是否开启optimizer_trace;on表示开启，off表示关闭。
one_line:是否开启单行存储。on表示开启;off表示关闭，将会用标准的JSON格式化存储。设置成on将会有良好的格式，设置成off可节省一些空间。
optimizer_trace_features：控制optimizer_trace跟踪的内容，默认
值:greedy_search=on,range_optimizer=on,dynamic_range=on,repeated_subselect=on greedy_search:是否跟踪贪心搜索。
range_optimizer:是否跟踪范围优化器 dynamic_range:是否跟踪动态范围优化，表示开启所有跟踪项。
repeated_subselect:是否跟踪子查询，如果设置成off，只跟踪第一条Item_subselect的执行。
optimizer_trace_limit:控制optimizer_trace展示多少条结果，默认1
optimizer_trace_max_mem_size:optimizer_trace堆栈信息允许的最大内存，默认1048576
optimizer_trace_offset:第一个要展示的optimizer trace的偏移量，默认-1。
end_markers_in_json:如果JSON结构很大，则很难将右括号和左括号配对。为了帮助读者阅读，可将其设置成 on，这样会在右括号附近加上注释，默认off。

总结分析

具体的分析性能介绍后续会在【举世无双的「MySQL调优金字塔」相信也许你拥有了它，你就很可能拥有了全世界。】进行深入介绍，此外还会伴有对索引原理的深入理解和分析。

独一无二的「MySQL调优金字塔」相信也许你拥有了它，你就很可能拥有了全世界。

开发俏皮话

技术金字塔

技术梗概

研发成本角度

技术可行性和效果角度

调优白皮书

业务需求和业务架构

SQL技术调优

调优的思路

发现问题（慢SQL的优化和分析）

发现慢SQL以及查询日志

使用方式-修改MySQL服务配置

使用方式-修改全局服务配置

分析慢SQ的查询日志

分析慢SQL日志文件

使用案例：

执行计划分析慢SQL

案例分析

id字段

select_type字段

table字段

partitions字段

type字段

system：

const:

eq_ref：

多表关联查询，单行匹配

多表关联查询，联合索引，多行匹配

ref

根据索引(非主键，非唯一索引)，匹配到多行

多表关联查询，单个索引，多行匹配

多表关联查询，联合索引，多行匹配

TIPS

fulltext：全文索引

ref_or_null

index_merge

unique_subquery

index_subquery

range

index

ALL

possible_keys

key

key_len

key_len计算公式

ref

rows

filtered

TIPS

Extra(重点分析)

Explain的命令讲解

特殊取值含义介绍

估计查询性能

SQL性能分析

SHOW PROFILE（旧版本的MySQL服务可使用,新版本已废弃）

NFORMATION_SCHEMA.PROFILING

该表包括以下字段:

采用show profile方式进行查询

INFORMATION_SCHEMA.PROFILING的查询方式

PERFORMANCE_SCHEMA(未来的继承者)

三种方式对比与选择

OPTIMIZER_TRACE相关参数

总结分析

你可能感兴趣的:(独一无二的「MySQL调优金字塔」相信也许你拥有了它，你就很可能拥有了全世界。)