B站黑马程序员《MySQL高级》：https://www.bilibili.com/video/BV1Kr4y1i7ru?p=75

步骤

在应用的开发过程中，由于初期数据量小，开发人员写SQL语句时更重视功能上的实现，但是当应用系统正式上线后，随着生产数据量的急剧增长，很多SQL语句开始逐渐显露出性能问题，对生产的影响也越来也大，此时这些有问题的SQL语句就成为整个系统性能的瓶颈，因此我们必须要对它们进行优化。

当面对一个有SQL性能问题的数据库时，我们应该从何处入手来进行系统的分析，使得能够尽快定位问题SQL并尽快解决问题？

1、查看SQL执行频率

MySQL客户端连接成功后，通过show [session | global] status命令可以提供服务器状态信息。该命令可以根据需要加上参数session或者global来显示session级（当前连接）的统计结果、和global级（自数据库上次启动至今）的统计结果。如果不写，默认使用参数为session。

-- 显示当前session中所有统计参数的值
show status like 'Com_______';

show global status like 'Innodb_rows_%';

Com_xxx表示每个xxx语句执行的次数，我们通常比较关心的是以下几个统计参数：

参数	含义
Com_select	执行select操作的次数，一次查询只累加1
Com_insert	执行INSERT操作的次数，对于批量插入的INSERT操作，只累加1次
Com_update	执行UPDATE操作的次数
Com_delete	执行DELETE操作的次数
Innodb_rows_read	select查询返回的行数
Innodb_rows_inserted	执行INSERT操作插入的行数
Innodb_rows_updated	执行UPDATE操作更新的行数
Innodb_rows_deleted	执行DELETE操作删除的行数
Connections	试图连接MYSQL服务器的次数
Uptime	服务器工作时间
Slow_queries	慢查询的次数

Com_***：这些参数对于所有存储引擎的表操作都会进行累计。Innodb_***：这几个参数只是针对InnoDB存储引擎的，累加的算法也略有不同。

2、定位低效率执行SQL

可以通过以下两种方式定位执行效率低的SQL语句。

• 慢查询日志：通过慢查询日志定位那些执行效率较低的SQL语句，用--log-slow-queries[=file_name]选项启动时，mysqlId写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件。

• show processlist：慢查询日志在查询结束以后才记录，所有在应用反映执行效率出现问题的时候查询日志并不能定位问题，可以使用show processlist 命令查看当前MySQL在进行的线程，包括线程的状态、是否锁表等，可以实时地查看SQL的执行情况，同时对一些锁表操作进行优化。

1、id列，用户登录mysql时，系统分配的“connection_id”，可以使用函数connection_id()查看
2、user列，显示当前用户。如果不是root，这个命令就只显示用户权限范围的sql语句
3、host列，显示这个语句是从哪个ip的哪个端口上发的，可以用来跟踪出现问题语句的用户
4、db列，显示这个进程目前连接的是哪个数据库
5、command列，显示当前连接的执行的命令，一般取值为休眠（sleep）、查询（query）、连接（connect）等
6、time列，显示这个状态持续的时间，单位为秒
7、state列，显示使用当前连接的sql语句的状态，很重要的列。state描述的是语句执行中的某一个状态。
   一个sql语句，以查询为例，可能需要经过copying to tmp table、sorting result、sending data等状态才可以完成
8、info列，显示这个sql语句，是判断问题语句的一个重要依据

3、explain分析执行计划

通过以上步骤查询到效率低的SQL语句后，可以通过EXPLAIN或者DESC命令获取MySQL如何执行select语句的信息，包括在select语句执行过程中如何连接和连接的顺序。

查询SQL语句的执行计划：

explain select * from tb_item where id = 1;

字段	含义
id	select查询的序列号，是一组数字，表示的是查询中执行select子句或者是操作表的顺序
select_type	表示SELECT的类型，常见的取值有SIMPLE（简单表，即不使用表连接或者子查询）、PRIMARY（主查询，即外层的查询）、UNION（UNION中的第二个或者后面的查询语句）、SUBQUERY（子查询中的第一个SELECT）等
table	输出结果集的表
type	表示表的连续类型，性能由好到差的连接类型为（system→const→eq_ref→ref→ref_or_null→index_merge→index_subquery→range→index→all）
possible_keys	表示查询时，可能使用的索引
key	表示实际使用的索引
key_len	索引字段的长度
rows	扫描行的数量
extra	执行情况的说明和描述

id：select查询的序列号，是一组数字，表示的是查询中执行select子句或者是操作表的顺序。id情况有三种：

• id相同表示加载表的顺序是从上到下。

• id不同id值越大，优先级越高，越先被执行。

• id有相同，也有不同，同时存在。id相同的可以认为是一组，从上往下顺序执行，在所有的组中，id的值越大，优先级越高，越先执行。

select_type：表示select的类型，常见的取值，如下表所示：

select_type	含义
SIMPLE	简单的select查询，查询中不包含子查询或者UNION
PRIMARY	查询中若包含任何复杂的子查询，最外层查询标记为该标识
SUBQUERY	在select或where列表中包含了子查询
DERIVED	在from列表中包含的子查询，被标记为DERIVED（衍生）MYSQL会递归执行这些字查询，把结果放在临时表中
UNION	若第二个select出现在union之后，则标记为union；若union包含在from子句的子查询中，外层select将被标记为：DERIVED
UNION RESULT	从UNION表获取结果的select

table：展示这一行的数据是关于哪一张表的。

type：显示的是访问类型，是较为重要的一个指标，可取值为：

type	含义
NULL	MySQL不访问任何表，索引，直接返回结果
system	表只有一行记录（等于系统表），这是const类型的特例，一般不会出现
const	表示通过索引一次就找到了，const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快。如将主键置于where列表中，MySQL就能将查询转换为一个常量。const将主键或唯一索引的所有部分与常量值进行比较
eq_ref	类似ref，区别在于使用的是唯一索引，使用主键的关联查询，关联查询出的记录只有一条。常见于主键或唯一索引扫描
ref	非唯一性索引扫描，返回匹配某个单独值的所有行。本质上也是一种索引访问，返回所有匹配某个单独值所有行（多个）
range	只检索给定返回的行，使用一个索引来选择行。where之后出现between、<、>、in等操作
index	index与all的区别为index类型只是遍历了索引数，通常比all快，all是遍历数据文件
all	将遍历全表以找到匹配的行

一般来说，我们需要保证查询至少达到range级别，最好达到ref。

key：实际使用的索引，如果为NULL，则没有使用索引。

possible_keys：显示可能应用在这张表的索引，一个或多个。

key：实际使用的索引，如果为NULL，则没有使用索引。

key_len：表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下，长度越短越好。

rows：扫描行的数量。

extra：其它的额外的执行计划信息，在该列展示。

extra	含义
using filesort	说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取，称为文件排序，效率低
using temporary	使用了临时表保存中间结果，mysql在对查询结果排序时使用临时表。常见于order by和group by
using index	表示相应的select操作使用了覆盖索引，避免访问表的数据行，效率不错

show profile分析SQL

MySQL从5.0.37版本开始增加了对show profiles和show profile语句的支持。show profiles能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。

通过have_profiling参数，能够看到当前MySQL是否支持profile：select @@have_profiling;。默认profiling是关闭的（select @@profiling；），可以通过set语句在Session级别开启profiling。

set profiling=1; --开启profiling开关

通过profile，我们能够更清楚地了解SQL执行的过程。

首先，我们可以执行一系列的操作，再执行show profiles指令，来查看SQL语句执行的耗时：

通过show profile for query query_id语句可以查看到该SQL执行过程中每个线程的状态和消耗的时间：

Sending data 状态表示MySQL线程开始访问数据行并把结果返回给客户端，而不仅仅是返回客户端。由于在Sending data状态下，MySQL线程往往需要做大量的磁盘读取操作，所以经常是整个查询中耗时最长的状态。

在获取到最消耗时间的线程状态后，MySQL支持进一步选择all、cpu、block io、context switch、page faults等明细类型类查看MySQL在使用什么资源上耗费了过高的时间。例如，选择查看CPU的耗费时间：

trace分析优化器执行计划

MySQL5.6提供了对SQL的跟踪trace，通过trace文件能够进一步了解为什么优化器选择A计划，而不是B计划。

打开trace，设置格式为JSON，并设置trace最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整展示。

SET optimizer_trace="enabled=on",end_markers_in_json=on;
SET optimizer_trace_max_mem_size=1000000

执行SQL语句：select * from tb_item where id <= 4;。

最后，检查information_schema.optimizer_trace就可以知道MySQL是如何执行SQL的：

select * from information_schema.optimizer_trace\G;

索引的使用

索引是数据库优化最常用也是最重要的手段之一，通过索引通常可以帮助用户解决大多数的MySQL的性能优化问题。

-- 根据id查询,查询速度很快，主要原因是id是主键，有索引
select * from tb_item where id = 1999\G;
-- 根据name查询，速度慢，因为name没有索引
select * from tb_item where name = '张三';
-- 解决方案，针对name字段，创建索引
create index idx_item_name on tb_item(name);

避免索引失效

1、全值匹配，对索引中所有列都指定具体值。该情况下，索引生效，执行效率高。

-- 创建联合索引
create index idx_seller_name_sta_addr on tb_seller(name,status,address);
-- 测试
explain select * from tb_seller where name = '小米科技' and status = '1' and address = '北京市'\G;

2、最左前缀法则

如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始，并且不跳过索引中的列。

匹配最左前缀法则，走索引：（与查询条件的顺序无关，只看查询的条件包不包含）

-- 此时name走索引，address不走索引
explain select * from tb_seller where name = '小米科技' and address = '北京市';

3、范围查询右边的列，不能使用索引。

根据前面的两个字段name、status查询时走索引的，但是最后一个条件address没有用到索引。（范围查询后的字段索引失效）

4、不要在索引列上进行运行操作，索引将失效。

5、字符串不加单引号，造成索引失效。（底层会对字符串隐式运算操作）

6、尽量使用覆盖索引（只访问索引的查询，即索引列完全包含查询列），避免select *。如果查询列超出索引列，也会降低性能。

using index：使用覆盖索引的时候就会出现
using where：在查找使用索引的情况下，需要回表去查询所需的数据
using index condition：查找使用了索引，但是需要回表查询数据
using index; using where：查找使用了索引，但是需要的数据都在索引列中能找到，所以不需要回表查询数据

7、用or分割开的条件，如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。

-- name字段是索引列，而createtime不是索引列，中间是or进行连接是不走索引的
explain select * from tb_seller where name='张三' or createtime='2020-01-01 12:00:00';

8、以%开头的like模糊查询，索引失效。如果仅仅是尾部模糊查询，索引不会失效。如果是头部模糊查询，索引失效。

解决方案：通过覆盖索引来解决。

explain select sellerid,name,status,address from tb_seller where name like '%科技%';

9、如果MySQL评估使用索引比全表更慢，则不使用索引。

10、is NULL，is NOT NULL 有时索引失效。（根据数据库数据量决定，如果NULL值比较多，is NOT NULL走索引，反之亦然）

11、in 走索引，not in索引失效。

12、单列索引和复合索引。尽量使用复合索引，而少使用单列索引。

-- 就相当于创建了三个索引：name、name+status、name+status+address
create index idx_name_sta_address on tb_seller(name,status,address);

-- 创建单列索引，数据库会选择一个最优的索引（辨识度最高的索引）来使用，并不会使用全部索引

查看索引使用情况

show status like 'Handler_read%';
show global status like 'Handler_read%';

Handler_read_first：索引中第一条被读的次数。如果越高，表示服务器正执行大量全索引扫描（这个值越低越好）
Handler_read_key：如果索引正在工作，这个值代表一个行被索引值读的次数，如果值越低，表示索引得到的性能改善不高，因为索引不经常使用（这个值越高越好）。
Handler_read_next：按照键顺序读下一行的请求数。如果你用范围约束或如果执行索引扫描来查询索引列，该值增加。
Handler_read_prev：按照键顺序读前一行的请求数。该读方法主要用于优化ORDER BY ... DESC。
Handler_read_rnd：根据固定位置读一行的请求数。如果你正执行大量查询并需要对结果进行排序该值较高。
    你可能使用了大量需要MySQL扫描整个表的查询或你的连接没有正确使用键。这个值较高，意味着运行效率低，应该建立索引来补救。
Handler_read_rnd_next：在数据文件中读下一行的请求数。如果你正进行大量的表扫描，该值较高。通常说明你的表索引不正确或写入的查询没有利用索引。    

SQL优化

大批量插入数据

当使用load命令导入数据的时候，适当的设置可以提高导入的效率。

对于InnoDB类型的表，有以下几种方式可以提高导入的效率：

1、主键顺序插入

因为InnoDB类型的表是按照主键的顺序保存的，所以将导入的数据按照主键的顺序排列，可以有效的提高导入数据的效率。如果InnoDB表没有主键，那么系统会自动默认创建一个内部列作为主键，所以如果可以给表创建一个主键，将可以利用这点，来提高导入数据的效率。

load data local infile '/root/sql.log' into table `tb_user` fields terminated by ',' lines terminated by '\n';

2、关闭唯一性校验

在导入数据前执行SET UNIQUE_CHECKS=0;，关闭唯一性效验，在导入结束后执行SET UNIQUE_CHECKS=1，恢复唯一性效验，可以提高导入的效率。

3、手动提交事务

如果应用使用自动提交的方式，建议在导入前执行SET AUTOCOMMIT=0，关闭自动提交，导入结束后再执行SET AUTOCOMMIT=1，打开自动提交，也可以提高导入的效率。

优化insert语句

当进行数据的insert操作的时候，可以考虑采用以下几种优化方案：

1、如果需要同时对一张表插入很多行数据时，应该尽量使用多个值表的insert语句，这种方式将大大的缩减客户端与数据库之间的连接、关闭等消耗。使得效率比分开执行的单个insert语句快。

-- 原始方式
insert into tb_test values(1,'Tom');
insert into tb_test values(2,'Cat');

-- 优化后的方案
insert into tb_test values(1,'Tom'),(2,'Cat');

2、在事务中进行数据插入

start transaction;
insert into tb_test values(1,'Tom');
insert into tb_test values(2,'Cat');
commit;

3、数据有序插入

优化order by语句

两种排序方式

• 第一种是通过对返回数据进行排序，也就是通常说的filesort排序，所有不是通过索引直接返回排序结果的排序都叫FileSort排序。

• 第二种通过有序索引顺序扫描直接返回有序数据，这种情况即为using index，不需要额外排序，操作效率高。

尽量减少额外的排序，通过索引直接返回有序数据。where条件和order by 使用相同的索引，并且order by的顺序和索引顺序相同，并且order by 的字段都是升序，或者都是降序。否则肯定需要额外的操作，这样就会出现FileSort。

Filesort优化

通过创建合适的索引，能够减少Filesort的出现，但是在某些情况下，条件限制不能让Filesort消失，那就需要加快Filesort的排序操作。对于Filesort，MySQL有两种排序算法：

1、两次扫描算法：MySQL4.1以前，使用该方式排序。首先根据条件取出排序字段和行指针信息，然后在排序区sort buffer 中排序，如果sort buffer不够，则在临时表temporary table中存储排序结果。完成排序之后，再根据行指针回表读取记录，该操作可能会导致大量随机I/O操作。

2、一次扫描算法：一次性取出满足条件的所有字段，然后在排序区sort buffer中排序后直接输出结果集。排序时内存开销较大，但是排序效率比两次扫描算法要高。

MySQL通过比较系统变量max_length_for_sort_data 的大小和Query语句取出的字段总大小，来判定是否那种排序算法，如果max_length_for_sort_data更大，那么使用第二种优化之后的算法，否则使用第一种。

可以适当提高sort_buffer_size和max_length_for_sort_data系统变量，来增大排序区的大小，提高排序的效率。

show variables like 'sort_buffer_size';
show variables like 'max_length_for_sort_data';

优化group by语句

由于group by 实际上也同样会进行排序操作，而且与order by相比，group by主要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其它的一些聚合函数，那么还需要一些聚合函数的计算。所以，在group by的实现过程中，与order by一样也可以利用到索引。

如果查询包含group by但是用户想要避免排序结果的消耗，则可以执行order by null 禁止排序。如下：

drop index idx_emp_age_salary on emp;
explain select age,count(*) from emp group by age; --using temporary,using filesort(使用临时表和文件系统)

-- 优化后
explain select age,count(*) from emp group by age order by null; --using temporary

-- 创建索引(不使用临时表，使用索引)
create index idx_emp_age_salary on emp(age,salary);

优化嵌套查询

MySQL4.1版本后，开始支持SQL子查询。这个技术可以使用select语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是有些情况下，子查询是可以被更高效的连接（join）替代。

explain select * from t_user where id in (select user_id from user_role);
explain select * from t_user u,user_role ur where u.id = ur.user_id;

优化OR条件

对于包含or的查询子句，如果要利用索引，则or之间的每个条件列都必须用到索引，而且不能使用到复合索引；如果没有索引，则应该考虑增加索引。

explain select * from emp where id = 1 or age = 30;
-- 建议使用union替换or
explain select * from emp where id = 1 union select * from emp where age = 30;

我们来比较下重要指标，发现主要差别是type和ref两项

type显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge 
> unique_subquery > index_subquery > range > index > all

union 语句的type值为ref，or语句的type值为range，可以看到这是一个很明显的差距。

union 语句的ref值为const，or语句的type值为null，const表示是常量值引用，非常快。这两项的差距就说明了union要优于or。

优化分页查询

一般分页查询时，通过创建覆盖索引能够比较好地提高性能。一个常见又非常头疼的问题就是limit 2000000,10，此时需要MySQL排序前2000010记录，仅仅返回2000000-2000010的记录，其它记录丢弃，查询排序的代价非常大。

优化思路一

在索引上完成排序分页操作，最后根据主键关联回原表查询所需要的其它列内容。

explain select * from tb_item t ,
(select id from tb_item order by id limit 2000000,10) a 
where t.id = a.id;

优化思路二

该方案适用于主键自增的表，且主键不能断层。可以把limit查询转换成某个位置的查询。

explain select * from tb_item where id > 1000000 limit 10;

使用SQL提示

SQL提示，是优化数据库的一个重要手段，简单来说，就是在SQL语句中加入一些人为的提示来达到优化操作的目的。

use index

在查询语句中表名的后面，添加use index 来提供希望MySQL去参考的索引列表，就可以让MySQL不再考虑其它可用的索引。

create index idx_seller_name on tb_seller(name);
explain select * from tb_seller use index(idx_seller_name) 
where name = '小米科技';

ignore index

如果用户只是单纯的想让MySQL忽略一个或者多个索引，则可以使用ignore index作为hint。

explain select * from tb_seller ignore index(idx_seller_name) 
where name = '小米科技';

force index

为强制MySQL使用一个特定的索引，可在查询中使用force index作为hint。

create index idx_seller_address on tb_seller(address);
explain select * from tb_seller force index(idx_seller_address) 
where address='北京市';

应用优化

在实际生产环境中，由于数据库本身的性能局限，就必须要对前台的应用进行一些优化，来降低数据库的访问压力。

使用连接池

对于访问数据库来说，建立连接的代价是比较昂贵的，因为我们频繁的创建关闭连接，是比较耗费资源的，我们有必要建立连接池，以提高访问的性能。

减少对MySQL的访问

1、避免对数据进行重复检索

在编写应用代码时，需要能够理清对数据库的访问逻辑。能够一次连接就获取到结果的，就不用两次连接，这样可以大大减少对数据库无用的重复请求。

2、增加cache层

在应用中，我们可以在应用中增加缓存层来达到减轻数据库负担的目的。缓存层有很多种，也有很多实现方式，只要能达到降低数据库的负担又能满足应用需求就可以。

因此可以部分数据从数据库抽取出来放到应用端以文本方式存储，或者使用框架mybatis、hibernate提供的一级缓存/二级缓存，或者使用redis数据库来缓存数据。

负载均衡

负载均衡是应用中使用非常普遍的一种优化方法，它的机制就是利用某种均衡算法，将固定的负载量分布到不同的服务器上，以此来降低单台服务器的负载，达到优化的效果。

1、利用MySQL复制分流查询

通过MySQL的主从复制，实现读写分离，使增删改操作走主节点，查询操作走从节点，从而可以降低单台服务器的读写压力。

2、采用分布式数据库架构

分布式数据库架构适合大数据量、负载高的情况，它有良好的扩展性和高可用性。通过在多台服务器之间分布数据，可以实现在多台服务器之间的负载均衡，提高访问效率。

MySQL中查询缓存优化

概述

开启MySQL的查询缓存，当执行完全相同的SQL语句的时候，服务器就会直接从缓存中读取结果，当数据被修改，之前的缓存会失效，修改比较频繁的表不适合做查询缓存。

操作流程

1、客户端发送一条查询给服务器。

2、服务器先会检查查询缓存，如果命中了缓存，则立即返回存储在缓存中的结果。否则进入下一阶段。

3、服务器端进行SQL解析、预处理，再由优化器生成对应的执行计划。

4、执行计划会查询执行引擎，通过存储引擎查询数据将结果返回给客户端，并将结果写入缓存中。

查询缓存配置

1、查看当前的MySQL数据库是否支持查询缓存：

show variables like 'have_query_cache';

2、查看当前MySQL是否开启了查询缓存：

show variables like 'query_cache_type';

3、查看查询缓存的占用大小：

show variables like 'query_cache_size'; --单位：字节

4、查看查询缓存的状态变量：

show status like 'Qcache%';

开启查询缓存

MySQL的查询缓存默认是关闭的，需要手动配置参数query_cache_type，来开启查询缓存。query_cache_type该参数的可取值有3个：

值	含义
OFF 或 0	查询缓存功能关闭
ON 或 1	查询缓存功能打开，select 到的结果符合缓存条件即会缓存，否则，不予缓存，显式指定SQL_NO_CACHE，不予缓存
DEMAND 或 2	查询缓存功能按需进行，显式指定SQL_CACHE的select语句才会缓存，其它均不予缓存

在/usr/my.cnf配置中，增加以下配置：

# 开启mysql的查询缓存
query_cache_type=1

配置完毕后，重启服务即可生效。

查询缓存select选项

可以在select语句中指定两个与查询缓存相关的选项：

SQL_CACHE：如果查询结果是可缓存的，并且query_cache_type 系统变量的值为ON或DEMAND，则缓存查询结果。

SQL_NO_CACHE：服务器不使用查询缓存。它既不检查查询缓存，也不检查结果是否已缓存，也不缓存查询结果。

SELECT SQL_CACHE id,name FROM customer;
SELECT SQL_NO_CACHE id,name FROM customer;

查询缓存失效的情况

1、SQL语句不一致的情况，要想命中查询缓存，查询的SQL语句必须一致。（SQL语句的大小写也要一致）

2、当查询语句中有一些不确定的时，则不会缓存。如：now()，current_date()，curdate()，curtime()，rand()，uuid()，user()，database()。

select * from tb_item where updatetime < now() limit 1;
select user();
select database();

3、不使用任何查询语句。

select 'A';

4、查询mysql，information_schema 或 performance_schema 数据库中的表时，不会走查询缓存。

select * from information_schema.engines;

5、在存储的函数，触发器或事件的主体内执行的查询。

6、如果表更改，则使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除。这包括使用MERGE映射到已更改表的表的查询。一个表可以被许多类型的语句，如被改变insert、update、delete、truncate table、alter table、drop table 或drop database。