一、前言

我们在做SQL优化的时候，应该从哪几方面定位SQL执行慢的原因呢？是索引设计的问题？参数配置的问题？还是需要扩容了呢？

本文介绍了比较常用的三种工具来定位和分析慢SQL，本文主要内容如下：

1. 通过慢查询日志定位执行慢的 SQL；
2. 使用 EXPLAIN 分析该 SQL 语句是否使用到了索引，以及具体的数据表访问方式；
3. 使用SHOW PROFILE 进一步分析SQL的每一步执行时间以及CPU、IO等资源使用情况。

二、慢查询日志定位执行慢的 SQL

慢查询日志是MySQL提供的一种日志记录，它用来记录所有执行时间超过long_query_time参数值的SQL。long_query_time的默认值为10秒，默认情况下执行超过10s的SQL语句，会被记录到慢查询日志中。

2.1.开启慢查询日志

在使用前，我们需要先看下慢查询是否已经开启，使用下面这条命令查看是否开启：

show variables like '%slow_query_log%';

slow_query_log=OFF，表示未开启。 slow_query_log=ON表示慢查询已经开启，如果未开启，通过以下命令开启：

set global slow_query_log='ON';

开启后，使用show variables like '%slow_query_log%'再来看下是否开启

slow_query_log_file 是慢查询日志文件目录。

Mysql支持文件和数据库表两种日志存储方式，默认将日志存储在文件中，使用下面这条命令查看存储方式：

show variables like '%log_output%';

可以修改为存储到数据库表，这样日志信息就会被写入到mysql.slow_log表中

set global log_output='TABLE';

MySQL数据库同时支持两种日志存储方式，配置的时候以逗号隔开即可

set global log_output='TABLE,FILE';

日志记录到系统的专用日志表中，要比记录到文件耗费更多的系统资源，因此对于需要启用慢查询日志，又需要能够获得更高的系统性能，那么建议优先记录到文件。

2.2.设置慢查询的时间阈值

long_query_time的默认值为10秒，通过以下命令可以查看慢查询的时间阈值

show variables like '%long_query_time%';

如果我们想修改long_query_time参数值，通过以下命令即可，假如我们把long_query_time值设置为1。

set global long_query_time = 1;

注意：修改完再次执行show variables like ‘%long_query_time%’，发现还是默认的10S，是不是没有修改成功呢？其实已经修改成功了，此时只需要关闭当前连接，再重新连接就可以了。

使用set global slow_query_log=1开启了慢查询日志只对当前数据库生效，如果MySQL重启后则会失效。如果要永久生效，需要修改my.cnf配置文件，配置文件如下：

[mysqld] 
slow_query_log = 1   # 开启慢查询
slow_query_log_file = /data/mysql/logs/slow.log   # 慢查询日期路径
long_query_time = 1  # 慢查询时间阈值
log_timestamps = SYSTEM
log_output = FILE

2.3. 慢查询日志介绍

模拟慢查询

如果自己mysql上没有慢查询，可以通过sleep(N)函数来模拟慢查询操作，比如下面这条模拟慢查询的语句

SELECT *, sleep(3) FROM tb_user WHERE id<4

注意：sleep(N)函数表示，每返回一行数据经过WHERE条件判断后，都会触发Sleep函数，比如上面的SQL语句，返回3条数据，每条阻塞3秒，查询时间总共是9秒。

慢查询日志

有了慢查询日志，可以使用以下命令获取有多少条日志

show global status like '%Slow_queries%';

可以看到现在有两条慢查询，接下来我们来看下慢查询日志具体记录哪些内容

# Time: 2022-01-22T12:56:00.070149Z
# User@Host: root[root] @ localhost []  Id:     8
# Query_time: 4.006927  Lock_time: 0.000074 Rows_sent: 4  Rows_examined: 4
SET timestamp=1642856160;
SELECT *, sleep(1) FROM tb_user WHERE id<5;

第一行记录的是该条 SQL 语句执行的时间；

第二行记录的是执行该SQL语句的用户和 IP 以及链接 id；

第三行的几个字段解释如下：

• Query_time: duration 语句执行时间，以秒为单位。
• Lock_time: duration 获取锁的时间(以秒为单位)。
• Rows_sent: 发送给 Client 端的行数。
• Rows_examined: 服务器层检查的行数(不计算存储引擎内部的任何处理)

第四行记录是此SQL语句执行时候的时间戳；

第五行就是具体的慢SQL。也是我们需要优化的SQL。

2.4.日志分析工具mysqldumpslow

MySQL 提供了 mysqldumpslow 工具统计慢查询日志。mysqldumpslow 命令的参数如下：

• -s：采用 order 排序的方式，排序方式可以有以下几种。分别是 c（访问次数）、t（查询时间）、l（锁定时间）、r（返回记录）、ac（平均查询次数）、al（平均锁定时间）、ar（平均返回记录数）和 at（平均查询时间）。其中 at 为默认排序方式。
• -t：返回前 N 条数据 。
• -g：后面可以是正则表达式，对大小写不敏感。

比如我们想要按照查询时间排序，查看前3条 SQL 语句，这样写即可：

 mysqldumpslow -s r -t 3 /var/lib/mysql/a7bb95cee15a-slow.log

得到访问次数最多的5个SQL

mysqldumpslow -s c -t 5  /var/lib/mysql/a7bb95cee15a-slow.log

得到按照时间排序的前5条里面含有左连接的查询语句。

mysqldumpslow -s t -t 10 -g “left join”  /var/lib/mysql/a7bb95cee15a-slow.log

另外建议在使用这些命令时结合 | 和more 使用 ，否则有可能出现刷屏的情况。

mysqldumpslow -s r -t 5  /var/lib/mysql/a7bb95cee15a-slow.log | more

三、查询优化神器EXPLAIN命令

MySQL 提供的 EXPLAIN 命令，它可以对 SELECT 语句进行分析，并输出 SELECT 执行的详细信息，开发人员可以根据输出的信息对SQL进行有针对性的优化。

EXPLAIN 可以帮助我们了解数据表的读取4,l;’]m np[ohfg]'顺序、SELECT 子句的类型、数据表的访问类型、可使用的索引、实际使用的索引、使用的索引长度、上一个表的连接匹配条件、被优化器查询的行的数量olhb.;/及额外的信息（比如是否使用了外部排序，是否使用了临时表等）等。

EXPLAIN使用方式如下，EXPLAIN 命令的输出内容如下：

下面对EXPLAIN 命令的输出各个字段进行说明

3.1. id字段

select查询的序列号，表示查询中执行select子句或操作表的顺序。

SQL 执行的顺序是根据 id 从大到小执行的，也就是 id 越大越先执行，当 id 相同时，从上到下执行。

比如下面这个SQL语句id一样，执行顺序按照从上到下执行。

EXPLAIN SELECT u.name,o.title FROM  tb_user u JOIN tb_order o ON u.id=o.user_id

下面的这条SQL语句，可以看到子查询的id为2，所以这条语句先执行是子查询

EXPLAIN SELECT * FROM tb_order WHERE user_id = (SELECT id FROM tb_user WHERE id=1)

3.2. select_type字段

表示查询的类型。常用的值如下表：

select_type字段值	说明
SIMPLE	表示查询语句不包含子查询或union
PRIMARY	表示此查询是最外层的查询
UNION	表示此查询是UNION的第二个或后续的查询
DEPENDENT UNION	UNION中的第二个或后续的查询语句，使用了外面查询结果
UNION RESULT	UNION的结果
SUBQUERY	SELECT子查询语句

平时我们最常见的查询类型是SIMPLE，表示我们的查询没有子查询也没用到UNION查询。

3.3. table字段

输出行所引用的表的名称。

3.4. partitions字段

该列显示的为分区表命中的分区情况。非分区表该字段为空（null）。

3.5. type字段

type字段表示存储引擎查询数据时采用的方式。这个也是我们平时做SQL优化重点关注的信息，通过它可以判断出查询是全表扫描还 是基于索引的部分扫描。type 常用属性值如下表所示：

type字段值	说明
ALL	全表扫描，性能最差。
index	表示基于索引的全表扫描，先扫描索引再扫描全表数据。
range	表示使用索引范围查询。使用>、>=、<、<=、in等等。
ref	表示采用了非唯一索引，或者是唯一索引的非唯一性前缀
eq_ref	一般情况下出现在多表join查询，表示前面表的每一个记录，都只能匹配后面表的一 行结果。
const	表最多有一个匹配行，因为只有一行，所以这一行中列的值可以被优化器视为常量
system	system 类型一般用于 MyISAM 或 Memory 表，属于 const 类型的特例

上面的这些type字段值，执行效率从上至下依次增强。效率从低到高依次为 all < index < range < index_merge < ref < eq_ref < const/system。

下面对type字段常用的类型做详细的说明

• all 是最坏的情况，因为采用了全表扫描的方式。

• index 和 all 差不多，只不过 index 对索引表进行全扫描，这样做的好处是不再需要对数据进行排序，但是开销依然很大。如果我们在 extra 列中看到 Using index，说明采用了索引覆盖，也就是索引可以覆盖所需的 SELECT 字段，就不需要进行回表，这样就减少了数据查找的开销。

  下面通过一个例子，来对index进行说明：

  比如我们有个tb_user表，对name和phone字段建立联合索引：

  CREATE INDEX name_phone_index on tb_user(`name`,phone)
  

  然后对数据表中的 name、phone 字段进行查询，EXPLAIN 执行计划如下：

从EXPLAIN执行结果中可以看到，这条SQL使用了index的方式，key列采用了联合索引（name_phone_index），进行了全表扫描。Extral 列为 Using index，告诉我们索引可以覆盖 SELECT 中的字段，也就不需要回表查询了。

• range 表示采用了索引范围扫描。比如下面这条SQL语句

  select * from tb_user where id>=1 and id<=5;
  

从range这一级别开始，索引的作用会越来越明显，因此我们需要尽量让 SQL 查询可以使用到 range 这一级别及以上的 type 访问方式。

• ref 类型表示采用了非唯一索引，或者是唯一索引的非唯一性前缀。

  比如我们对tb_order表user_id字段创建索引

  CREATE INDEX user_id_index on tb_order(user_id)
  

  然后查询user_id等于1的订单信息，EXPLAIN 执行计划如下：

  EXPLAIN SELECT title,order_datetime FROM tb_order WHERE user_id=1
  

这里 user_id 为普通索引，因此采用的访问类型是 ref，同时在 ref 列中显示 const，表示连接匹配条件是常量，用于索引列的查找。

• eq_ref 类型是使用主键或唯一索引时产生的访问方式，通常使用在多表联查中。

  比如我们对tb_order表和tb_user进行join关联查询

  EXPLAIN SELECT o.title,o.order_datetime,u.name FROM tb_order o
  JOIN tb_user  u ON o.user_id=u.id
  

  EXPLAIN 执行计划如下：

• const类型表示我们使用了主键或者唯一索引（所有的部分）与常量值进行比较。

  比如根据主键id查找某一个用户

在做优化的时候，最好可以使用到 range 这一级别及以上的 type 访问方式，如果只使用到了 all 或者 index 这一级别的访问方式，我们可以从 SQL 语句和索引设计的角度上进行改进。

3.6. possible_keys字段

表示查询时可能能使用到的索引。实际并不一定会真正使用。

3.7. key字段

表示查询时真正使用到的索引，显示的是索引名称。

3.8. rows字段

MySQL查询优化器会根据统计信息，估算SQL要查询到结果需要扫描多少行记录。原则上rows是 越少效率越高，可以直观的了解到SQL效率高低。

3.9. key_len字段

表示查询使用了索引的字节数量。可以判断是否全部使用了组合索引。

key_len的计算规则如下：

• 字符串类型
  字符串长度跟字符集有关，常见编码长度：gbk=2、utf8=3、utf8mb4=4
  char(n)：n*字符集长度
  varchar(n)：n * 字符集长度 + 2字节

• 数值类型

  TINYINT：1个字节
  SMALLINT：2个字节
  MEDIUMINT：3个字节
  INT、FLOAT：4个字节
  BIGINT、DOUBLE：8个字节

• 时间类型

  DATE：3个字节

  TIMESTAMP：4个字节

  DATETIME：8个字节

3.10. Extra字段

Extra表示很多额外的信息，各种操作会在Extra提示相关信息，常见几种如下：

• Using where 表示查询需要通过索引回表查询数据。
• Using index 表示查询需要通过索引，索引就可以满足所需数据。
• Using filesort 表示查询出来的结果需要额外排序，数据量小在内存，大的话在磁盘，因此有Using filesort 建议优化。
• Using temprorary 查询使用到了临时表，一般出现于去重、分组等操作。

总结

在使用EXPLAIN分析慢SQL的时候，我们主要关注type字段，最好可以使用到 range 这一级别及以上的 type 访问方式，如果只使用到了 all 或者 index 这一级别的访问方式，我们可以从 SQL 语句和索引设计的角度上进行改进。

其次关注rows字段，绝大部分rows小的语句执行一定很快，所以优化语句基本上都是在优化rows。

四、SQL性能分析show profile命令

show profile 相比 EXPLAIN 能看到更进一步的执行解析，包括 SQL 都做了什么、所花费的时间等。

默认情况下，show profile 是关闭的，使用下面的命令查看状态

mysql> show variables like 'profiling';

通过设置 profiling='ON’来开启 show profile：

mysql > set profiling = 'ON';

show profile命令只是在本会话内起作用，即无法分析本会话外的语句。开启分析功能后，所有本会话中的语句都被分析（甚至包括执行错误的语句），除了SHOW PROFILE和SHOW PROFILES两句本身。

查看当前会话都有哪些 profiles，使用下面这条命令：

mysql > show profiles;

使用下面的命令我们可以查看上一个查询的开销：

mysql > show profile;

可以给show profile 指定一个 for query id 来查看指定 id 的语句，比如查看Query_ID为4的SQL信息

mysql> show profile for query 4;

还可以给输出添加新的列，取值范围可以如下：

• ALL 显示所有性能信息
• BLOCK IO 显示块IO操作的次数
• CONTEXT SWITCHES 显示上下文切换次数，不管是主动还是被动
• CPU 显示用户CPU时间、系统CPU时间
• IPC 显示发送和接收的消息数量
• PAGE FAULTS 显示页错误数量
• SOURCE 显示源码中的函数名称与位置
• SWAPS 显示SWAP的次数

比如：

mysql> show profile cpu,block io,swaps for query 4;

通过上面的结果，我们可以弄清楚每一步骤的耗时，以及在不同部分，比如 CPU、block io 的执行时间，这样我们就可以判断出来 SQL 到底慢在哪里。

五、总结

本文介绍了MySQL性能分析常用的三种工具（还有很多性能分析工具），通过慢查询日志定位执行慢的 SQL，然后通过 EXPLAIN 分析该 SQL 语句是否使用到了索引和具体的数据表访问方式是怎样的。如果有需要最后再使用 SHOW PROFILE 进一步了解 SQL 每一步的执行时间，包括CPU 、I/O 等资源的使用情况。

通过上面介绍的这三种工具我们可以快速的定位和分析慢SQL，然后做出相应的优化。

参考文档：

《高性能MySQL》

• https://dev.mysql.com/doc/refman/8.0/en/explain-output.html

• https://dev.mysql.com/doc/refman/8.0/en/show-profile.html

• https://www.cnblogs.com/kerrycode/p/5593204.html

什么是死锁

死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时，就可能会产生死锁。多个事务同时锁定同一个资源时，也会产生死锁。例如，设想下面两个事务同时处理StockPrice表：

事务1

START TRANSACTION;
UPDATE StockPrice SET close = 45.50 WHERE stock_id = 4 and date = '2002-05-01';
UPDATE StockPrice SET close = 19.80 WHERE stock_id = 3 and date = '2002-05-02';
COMMIT;

事务2

 START TRANSACTION;
UPDATE StockPrice SET high = 20.12 WHERE stock_id = 3 and date = '2002-05-02';
UPDATE StockPrice SET high = 47.20 WHERE stock_id = 4 and date = '2002-05-01';
COMMIT;

如果凑巧，两个事务都执行了第一条UPDATE语句，更新了一行数据，同时也锁定了该行数据，接着每个事务都尝试去执行第二条UPDATE语句，却发现该行已经被对方锁定，然后两个事务都等待对方释放锁，同时又持有对方需要的锁，则陷入死循环。除非有外部因素介入才可能解除死锁。

为了解决这种问题，数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误。这种解决方式很有效，否则死锁会导致出现非常慢的查询。还有一种解决方式，就是当查询的时间达到锁等待超时的设定后放弃锁请求，这种方式通常来说不太好。InnoDB目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚（这是相对比较简单的死锁回滚算法）。

锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则完全是由于存储引擎的实现方式导致的。

死锁发生以后，只有部分或者完全回滚其中一个事务，才能打破死锁。对于事务型的系统，这是无法避免的，所以应用程序在设计时必须考虑如何处理死锁。大多数情况下只需要重新执行因死锁回滚的事务即可。

如何避免死锁

1. 类似的业务逻辑以固定的顺序访问表和行(基本上是可以解决大部分的问题,比如转账,所有的功能接口都是先减钱再加钱)
2. 大事务拆小,大事务更倾向于死锁,如果业务允许,将大事务拆小
3. 在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁概率
4. 降低隔离级别,如果业务允许,将隔离级别调低也是较好的选择(有点扯淡,但是也管用.)
   5 为表添加合理的索引,可以看到如果不走索引将会为表的每一行记录添加上锁(或者说是表锁)
   不加索引的事务语句拿到的锁都是表锁,表锁级别大,死锁概率就高了.

查看死锁日志

死锁场景:
事务A操作 select * from table where id =1 for update
事务B操作 select * from table where id =2 for update
事务A操作 select * from table where id =2 for update
事务B操作 select * from table where id =1 for update
此时就卡住了事务A等着事务B释放锁,事务B等着事务A释放锁.
解决办法很简单,就是找DBA看一下死锁日志就可以了,然后根据对应的SQL,找到对应的代码去改一下就可以了.
show engine innodb status 命令是可以查看死锁的信息的

如何阅读MySQL的死锁日志

https://www.yuque.com/docs/share/016b2375-68b1-4ad8-92e8-62eb71b24792?# 《MySQL如何阅读死锁日志》

死锁详细介绍

https://www.yuque.com/docs/share/e437b034-6813-4171-be8b-712279d7865c?# 《记一次线上SQL死锁事故：如何避免死锁？》

1、先登陆数据库mysql -uroot -p，然后使用命令：show engine innodb status;
    在命令的输出结果中，找到“LATEST DETECTED DEADLOCK”。
    从这段内容中在找到产生死锁的SQL语句（比如：replace into 和delete语句），以及产生死锁时直接原因，以及哪一个事务被回滚了。

2、手动复现死锁的场景：（记得将操作该表的程序都停掉，只有手动执行SQL）
    （1）打开3个MYSQL登陆shell界面，并且登陆。mysql -uroot -p
    （2）在2个shell界面中，分别设置为手动提交：set autocommit=0;
    （3）在2个shell界面，按出现死锁场景的语句执行顺序，手动在2个shell界面上执行SQL语句。
    （4）在第3个shell界面中，使用命令：select * from information_schema.innodb_locks;  可查看到当前锁等待的信息。

3、查看锁等待的信息，分析定位出死锁产生原因。解决死锁的方法有：
    （1）replace into冲突时：并行操作数据库，修改为串行操作数据库。
    （2）repalce into+delete死锁时：调整事务中的SQL语句执行顺序，把delete放前面。确保第1个SQL语句申请到更多的锁，避免第1个SQL语句申请少量锁，第2个SQL语句申请更多锁。
     

（mysql5.7）
查询隔离级别：
select @@tx_isolation;

自动提交关闭：mysql> set autocommit=0;

查询自动提交：mysql> select @@autocommit;

锁等待信息查询命令：
select * from information_schema.innodb_locks;

死锁产生的4个必要条件，参考文档：https://blog.csdn.net/guaiguaihenguai/article/details/80303835