大纲
1.Explain概述
2.Explain详解
3.索引优化数据准备
4.索引优化原则详解
5.慢查询设置与测试
6.慢查询SQL优化思路
1.Explain概述
使用Explain关键字可以模拟查询优化器来执行SQL查询语句，从而知道MySQL是如何处理SQL语句的，从而分析出查询语句和表结构的性能瓶颈。
MySQL查询过程：
通过Explain可以获得以下信息：
一.表的读取顺序
二.数据读取操作的操作类型
三.哪些索引可以被使用
四.哪些索引真正被使用
五.表的直接引用
六.每张表的有多少行被优化器查询了
Explain使用方式：Explain + SQL语句，通过执行Explain可以获得SQL语句执行的相关信息。
EXPLAIN SELECT * FROM L1;
2.Explain详解
(1)数据准备
(2)ID字段说明
(3)select_type和table字段说明
(4)type字段说明
(5)possible_keys与key说明
(6)key_len字段说明
(7)ref字段说明
(8)rows字段说明
(9)filtered字段说明
(10)extra字段说明
(1)数据准备
-- 创建数据库
CREATE DATABASE test CHARACTER SET 'utf8';
-- 创建表
CREATE TABLE L1(id INT PRIMARY KEY AUTO_INCREMENT,title VARCHAR(100) );
CREATE TABLE L2(id INT PRIMARY KEY AUTO_INCREMENT,title VARCHAR(100) );
CREATE TABLE L3(id INT PRIMARY KEY AUTO_INCREMENT,title VARCHAR(100) );
CREATE TABLE L4(id INT PRIMARY KEY AUTO_INCREMENT,title VARCHAR(100) );
-- 每张表插入3条数据
INSERT INTO L1(title) VALUES('test001'),('test002'),('test003');
INSERT INTO L2(title) VALUES('test004'),('test005'),('test006');
INSERT INTO L3(title) VALUES('test007'),('test008'),('test009');
INSERT INTO L4(title) VALUES('test010'),('test011'),('test012');
(2)ID字段说明
ID字段代表SELECT查询的序列号，它是一组数字，表示的是查询或操作表的顺序。
一.ID相同，执行顺序就是由上至下
EXPLAIN SELECT * FROM L1,L2,L3 WHERE L1.id=L2.id AND L2.id = L3.id;
二.ID不同，如果有子查询，ID号会递增
ID值越大优先级越高，越先被执行。
EXPLAIN SELECT * FROM L2 WHERE id = (
SELECT id FROM L1 WHERE id = (SELECT L3.id FROM L3 WHERE L3.title = 'test007')
);
(3)select_type和table字段说明
select_type表示查询类型，主要用于区别普通查询还是子查询等，table表示被操作的表。
一.SIMPLE：简单的SELECT查询，查询中不包含子查询或者UNION
EXPLAIN SELECT * FROM L1 where id = 1;
二.PRIMARY：在有子查询的情况下，最外层被标记为PRIMARY
三.SUBQUERY：在SELECT或WHERE列表中包含了子查询
EXPLAIN SELECT * FROM L2 WHERE id = (
SELECT id FROM L1 WHERE id = (SELECT L3.id FROM L3 WHERE L3.title = 'test08')
);
四.UNION：UNION连接的两个SELECT查询
在使用UNION时，左边的表的select_type是DERIVED，右边的表的select_type是UNION。
五.DERIVED：在FROM列表中包含的子查询被标记为DERIVED派生表
MySQL会递归执行这些被标记为DERIVED的子查询，然后把结果放到临时表中。
六.UNION RESULT：UNION的结果
EXPLAIN SELECT * FROM (SELECT * FROM L3 UNION SELECT * FROM L4) a;
(4)type字段说明
type字段表示的是连接类型，描述了找到所需数据而使用的扫描方式。
下面给出各种连接类型，按照从最好类型到最差类型进行排序：system -> const -> eq_ref -> ref -> fulltext -> ref_or_null -> index_merge -> unique_subquery -> index_subquery -> range -> index -> ALL
简化后，可以只关注以下几种 ：system -> const -> eq_ref -> ref -> range -> index -> ALL
一般来说，需要保证查询至少达到range级别，最好能达到ref级别，否则就要就行SQL的优化调整。
下面介绍type字段不同值表示的含义：
一.system
表示表中仅有一行数据，这是const连接类型的一个特例，很少出现。
二.const
表示命中主键索引(primary key)或唯一索引(unique)，通过主键索引或唯一索引一次就找到了数据。因为只匹配一条记录，所以被连接的部分是一个常量。如果将主键放在where条件中，MySQL就能将该查询转换为一个常量。这种类型非常快，例如以下查询：
EXPLAIN SELECT * FROM L1 WHERE id = 3;
-- 为L1表的title字段添加唯一索引
ALTER TABLE L1 ADD UNIQUE(title);
EXPLAIN SELECT * FROM L1 WHERE title = 'test001';
三.eq_ref
表示的是使用了唯一索引。比如连表查询中，对于前一个表中的每一行，后表只有一行被扫描。除了system和const类型之外，这是最好的连接类型。只有在连表时使用的索引都是主键或唯一索引时，才会出现这种类型，例如以下查询：
EXPLAIN SELECT L1.id,L1.title FROM L1 LEFT JOIN L2 ON L1.id = L2.id;
四.ref
表示使用了普通索引，即非唯一性索引。比如连表时对于前表的每一行，后表可能有多于一行的数据被扫描，例如以下查询：
-- 为L1表的title字段添加普通索引
ALTER TABLE L1 ADD INDEX idx_title (title);
EXPLAIN SELECT * FROM L1 INNER JOIN L2 ON L1.title = L2.title;
-- 如果L1表的title字段没有唯一索引，只有普通索引，如下查询也是ref
EXPLAIN SELECT * FROM L1 WHERE title = 'test001';
五.range
表示的是进行了索引上的范围查询，检索了给定范围的行，比如between、in函数、>都是典型的范围查询，例如以下查询：
EXPLAIN SELECT * FROM L1 WHERE L1.id BETWEEN 1 AND 10;注意：当in函数中的数据很大时，可能会导致效率下降，最终不走索引。
六.index
当可以使用索引覆盖，但需要扫描全部索引记录时，则type为index。
当需要执行全表扫描，且需要对主键进行排序时，则type也为index。
所以如果type的值等于index，那么就需要进行优化了。因为出现index表示没有通过索引进行过滤，需要扫描索引的全部数据。index会遍历扫描索引树，比ALL快一些。如果索引文件过大，index的速度还是会很慢的。
总结：
当遍历二级索引不需要回表或者主键排序全表扫描时，type就为index。
注意：
使用索引进行排序分组时，可能会出现这种type值为index的情况。比如进行统计操作时，会出现type值为index的情况。
EXPLAIN SELECT * FROM L2 GROUP BY id ORDER BY id;
-- 该count查询需要通过扫描索引上的全部数据来计数
EXPLAIN SELECT count(*) FROM L2;
七.ALL
表示没有使用到任何索引，连表查询时对于前表的每一行，后表都要被全表扫描。
EXPLAIN SELECT * FROM L3 inner join L4 on L3.title = L4.title;
总结各类type类型的特点：
system：不进行磁盘IO，查询系统表，仅仅返回一条数据。
const：查找主键索引，最多返回1条或0条数据，属于精确查找。
eq_ref：查找唯一性索引，返回数据最多一条，属于精确查找。
ref：查找非唯一性索引，返回匹配的多条数据，属于精确查找。
range：查找索引中给定范围的行，属于范围查找(>、<、in、between)。
index：使用了索引但扫描全部了，比all快，因索引文件比数据文件小。
index：比如遍历二级索引不需要回表或者主键排序全表扫描。
all：不使用任何索引，直接进行全表扫描。
(5)possible_keys与key说明
一.possible_keys
表示可能用于查询的表上的索引。查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用。
二.key
表示实际使用的索引。若为null，则表示没有使用到索引或索引失效。查询中若使用了覆盖索引，则该索引仅出现在key列表中。
情形一：理论和实际都用到了索引
EXPLAIN SELECT * FROM L1 WHERE id = 1;情形二：理论上没有使用索引，但实际上使用了
EXPLAIN SELECT L3.id FROM L3;情形三：理论和实际上都没有使用索引
EXPLAIN SELECT * FROM L3 WHERE title = 'test007';
(6)key_len字段说明
表示索引中使用的字节数，通过该列可以计算查询中使用索引的长度。key_len字段能够帮我们检查是否充分利用了索引，ken_len越长越好，说明索引使用的越充分。
一.创建表
CREATE TABLE L5(
a INT PRIMARY KEY,
b INT NOT NULL,
c INT DEFAULT NULL,
d CHAR(10) NOT NULL
);
二.使用EXPLAIN进行测试
-- 下面的查询只用到了主键a的索引
EXPLAIN SELECT * FROM L5 WHERE a > 1 AND b = 1;观察key_len的值，用到了主键索引，是int类型的，所以key_len是4字节。
三.为b字段添加索引，进行测试
ALTER TABLE L5 ADD INDEX idx_b(b);
-- 执行SQL，这次将b字段也作为条件
EXPLAIN SELECT * FROM L5 WHERE a > 1 AND b = 1;ken_len还是4。
四.为c、d字段添加联合索引，然后进行测试
ALTER TABLE L5 ADD INDEX idx_c_b(c,d);
EXPLAIN SELECT * FROM L5 WHERE c = 1 AND d = 'A';c字段是int类型4个字节，d字段char(10)代表的是10个字符30个字节。因为数据库的字符集是utf8，一个字符3个字节。d字段是char(10)代表的是10个字符相当30个字节。多出的一个字节用来表示是联合索引。
下面这个例子虽然使用了联合索引，但没充分利用索引，还有优化空间。因为可以根据ken_len的长度推测出该联合索引只使用一部分。
EXPLAIN SELECT * FROM L5 WHERE c = 1;
(7)ref字段说明
表示的是显示索引的哪一列被使用了，如果可能的话，最好是一个常数。表示的是哪些列或常量被用于查找索引列上的值。
如下的”L1.id=1″中，由于1是常量，所以ref = const，此时的ref = const表示着查询过程中使用到了常量。
EXPLAIN SELECT * FROM L1 WHERE L1.id = 1;
(8)rows字段说明
表示MySQL为了找到所需的记录，一共访问了多少行(预估的)。L3中的title没有添加索引，所以L3中有3条记录，就需要访问3条记录。
EXPLAIN SELECT * FROM L3,L4 WHERE L3.id = L4.id AND L3.title LIKE 'test007';需要注意的是rows只是一个估算值，并不准确。所以rows行数过大的问题并不值得过多考虑，主要分析的还是索引是否使用正确了。
(9)filtered字段说明
它指返回结果的行占需要读到的行(rows列的值)的百分比。
(10)extra字段说明
Extra是EXPLAIN输出中另外一个很重要的列，该列显示MySQL在查询过程中的一些详细信息。
一.准备数据
CREATE TABLE users (
uid INT PRIMARY KEY AUTO_INCREMENT,
uname VARCHAR(20),
age INT(11)
);
INSERT INTO users VALUES(NULL, 'lisa', 10);
INSERT INTO users VALUES(NULL, 'lisa', 10);
INSERT INTO users VALUES(NULL, 'rose', 11);
INSERT INTO users VALUES(NULL, 'jack', 12);
INSERT INTO users VALUES(NULL, 'sam', 13);
二.Using filesort(需要进行文件排序)
执行结果Extra为Using filesort，说明得到所需结果集，需要对所有记录进行文件排序。表示执行的SQL语句性能极差，需要进行优化。
下面就是在一个没有建立索引的列上进行order by，此时会触发filesort。优化方案是，在order by的列上添加索引，避免每次查询都全量排序。
EXPLAIN SELECT * FROM users ORDER BY age;
三.Using temporary
表示使用了临时表来存储结果集，常见于排序和分组查询。
EXPLAIN SELECT COUNT(*),uname FROM users GROUP BY uname;
四.Using where
表示使用了全表扫描或者在查找时使用索引的情况下，还有查询条件不在索引字段中需要回表。
注意一：返回所有记录的SQL，不使用where条件过滤数据，大概率不符合预期，这类SQL往往需要进行优化。
注意二：使用了where条件的SQL，并不代表不需要优化，往往需要配合explain结果中的type(连接类型)来综合判断。例如下面查询的age未设置索引，所以返回的type为ALL，仍有优化空间，可建立索引优化查询。
EXPLAIN SELECT * FROM users WHERE age = 10;
五.Using index
表示直接访问索引就能获取所需数据(覆盖索引)，不需要回表。
-- 为uname创建索引
ALTER TABLE users ADD INDEX idx_uname(uname);
EXPLAIN SELECT uid,uname FROM users WHERE uname='lisa';
六.Using join buffer
表示使用了连接缓存，还会显示join连接查询时使用的算法。
EXPLAIN SELECT * FROM users u1 LEFT JOIN
(SELECT * FROM users WHERE age = 1) u2 ON u1.age = u2.age;Using join buffer(Block Nested Loop)说明，需要进行嵌套循环计算。这里每个表都有五条记录，内外表查询的type都为ALL。两个表通过字段age进行关联，且age字段未建立索引。
七.Using index condition
表示的是使用了索引，但是只使用了索引的一部分。一般发生在使用联合索引时，需要回表查询。
EXPLAIN SELECT * FROM L5 WHERE c > 10 AND d = '';
八.Extra主要指标的含义总结
using index：查找时使用了覆盖索引的时候就会出现，不需要回表。
using where：查找时使用索引的情况下需要回表或全表扫描。
using index condition：查找时使用了索引但只用一部分索引需要回表。
Using filesort：在一个没有建立索引的列上order by，发生文件排序。
Using temporary：使用了临时表存储结果集，常见于排序和分组查询。
当遍历二级索引不需要回表或者主键排序全表扫描时，type就为index。
查找非唯一性索引，返回匹配的多条数据，type就为ref。
查找唯一性索引，返回匹配的数据最多一条，type就为eq_ref。
查找索引中给定范围的行，type就为range。
3.索引优化数据准备
(1)创建数据库、表，插入数据
create database idx_optimize character set 'utf8';
CREATE TABLE users(
id INT PRIMARY KEY AUTO_INCREMENT,
user_name VARCHAR(20) NOT NULL COMMENT '姓名',
user_age INT NOT NULL DEFAULT 0 COMMENT '年龄',
user_level VARCHAR(20) NOT NULL COMMENT '用户等级',
reg_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间'
);
INSERT INTO users(user_name,user_age,user_level,reg_time)
VALUES('tom',17,'A',NOW()),('jack',18,'B',NOW()),('lucy',18,'C',NOW());
(2)创建联合索引
ALTER TABLE users ADD INDEX idx_nal (user_name,user_age,user_level) USING BTREE;
4.索引优化原则详解
(1)最左侧列匹配和最左前缀匹配法则
(2)不要在索引列上做任何计算
(3)范围之后全失效
(4)避免使用is null、is not null、!= 、or
(5)like以%开头会使索引失效
(6)索引优化原则总结
(1)最左侧列匹配和最左前缀匹配法则
如果创建的是联合索引，就要遵循该法则。where后面的条件需从索引的最左侧列开始，且不能跳过索引中的列。如果where只匹配一个列，那么该列在索引最左侧，且只匹配前缀字段。
一.最左侧列匹配和最左前缀匹配的场景
场景1：按照索引字段顺序使用，三个字段都使用了索引，没有问题。
EXPLAIN SELECT * FROM users
WHERE user_name = 'tom' AND user_age = 17 AND user_level = 'A';场景2：直接跳过user_name使用索引字段，索引无效，未使用到索引。
EXPLAIN SELECT * FROM users WHERE user_age = 17 AND user_level = 'A';场景3: 不按照创建联合索引的顺序，使用索引。
EXPLAIN SELECT * FROM users WHERE user_age = 17 AND user_name = 'tom' AND user_level = 'A';where后面查询条件顺序是user_age、user_level、user_name，这与创建的索引顺序user_name、user_age、user_level不一致。为什么还是使用了索引，原因是MySQL底层优化器对其进行了优化。
场景4：只要包含最左侧字段，索引就可以生效
但从key_len可知只是用到索引的一部分。
EXPLAIN SELECT * FROM users WHERE user_name = 'tom';
二.最左侧列匹配和最左前缀匹配的原理
InnoDB创建联合索引的规则是：
首先会对联合索引最左边的字段进行排序，例子中是user_name。在第一个字段的基础之上再对第二个字段进行排序，例子中是user_age。所以最佳左前缀原则其实是和B+树的结构有关系，最左字段肯定是有序的，第二个字段则是无序的。
联合索引的排序方式是：
先按第一个字段进行排序，如果第一个字段相等再根据第二个字段排序。所以如果直接使用第二个字段user_age通常是使用不到索引的。
(2)不要在索引列上做任何计算
不要在索引列上做任何操作，否则会导致索引失效，从而转向全表扫描。比如计算、使用函数、自动或手动进行类型转换(字符串不加双引号)。
一.插入数据
INSERT INTO users(user_name,user_age,user_level,reg_time) VALUES('11223344',22,'D',NOW());场景1：使用系统函数left()函数，对user_name进行操作
EXPLAIN SELECT * FROM users WHERE LEFT(user_name, 6) = '112233';场景2：字符串不加单引号(隐式类型转换)
对于varchar类型的字段，如果查询时不加单引号就会进行隐式转换，导致索引失效转向全表扫描。
EXPLAIN SELECT * FROM users WHERE user_name = 11223344;
(3)范围之后全失效
where条件中如果有范围条件，并且范围条件之后还有其他过滤条件，那么范围条件之后的列就都将会索引失效。
场景1：条件单独使用user_name时，type=ref、key_len=62。
-- 条件只有一个 user_name
EXPLAIN SELECT * FROM users WHERE user_name = 'tom';场景2：条件增加一个user_age(使用常量等值)，type= ref、key_len = 66。
EXPLAIN SELECT * FROM users WHERE user_name = 'tom' AND user_age = 17;场景3：使用全值匹配，type = ref、key_len = 128，索引都利用上了。
EXPLAIN SELECT * FROM users WHERE user_name = 'tom' AND user_age = 17 AND user_level = 'A';场景4：使用范围条件时，avg > 17、type = range、key_len = 66。与场景3比较，可发现user_level索引没用上。
EXPLAIN SELECT * FROM users WHERE user_name = 'tom' AND user_age > 17 AND user_level = 'A';
(4)避免使用is null、is not null、!= 、or
一.使用is null会使索引失效
EXPLAIN SELECT * FROM users WHERE user_name IS NULL;Impossible Where：表示where条件不成立，不能返回任何行。
二.使用is not null会使索引失效
EXPLAIN SELECT * FROM users WHERE user_name IS NOT NULL;
三.使用!=和or会使索引失效
EXPLAIN SELECT * FROM users WHERE user_name != 'tom';
EXPLAIN SELECT * FROM users WHERE user_name = 'tom' or user_name = 'jack';
(5)like以%开头会使索引失效
一.like查询中%出现在左边则索引失效，%出现在右边索引未失效
场景1：两边都有%或者%在左边，索引都会失效
EXPLAIN SELECT * FROM users WHERE user_name LIKE '%tom%';
EXPLAIN SELECT * FROM users WHERE user_name LIKE '%tom';场景2：%在右边，索引生效
EXPLAIN SELECT * FROM users WHERE user_name LIKE 'tom%';
二.解决%出现在左边索引失效的方法——使用覆盖索引
EXPLAIN SELECT user_name FROM users WHERE user_name LIKE '%jack%';
EXPLAIN SELECT user_name,user_age,user_level FROM users WHERE user_name LIKE '%jack%';对比场景1可以知道：通过使用覆盖索引type = index，并且extra = Using index，从原来的全表扫描变成了全索引扫描，也就是索引的全表扫描。
三.like失效的原理
原理一：%号在右
由于B+树的索引顺序，是按照首字母的大小进行排序，而%号在右时的匹配又会匹配首字母，所以能在B+树上进行有序的查找。也就是查找出首字母符合要求的数据，所以%号在右可以用到索引。
原理二：%号在左是匹配字符串尾部的数据
由于尾部的字母是没有顺序的，所以不能按索引顺序查询，用不到索引。
原理三：两个%%号
这个是查询任意位置的字母满足条件即可。只有首字母是进行索引排序的，其他位置的字母都是相对无序的，所以查找任意位置的字母是用不上索引的。
(6)索引优化原则总结
一.最左侧列匹配和最左前缀匹配
二.索引列上不计算不转换
三.范围之后全失效
四.最好使用覆盖索引
五.!=、is null、is not null、or会索引失效
六.like百分号加右边，加左边导致索引失效的解决方法是使用覆盖索引
5.慢查询设置与测试
(1)慢查询介绍
(2)慢查询参数
(3)慢查询配置方式
(4)慢查询测试
(5)慢日志内容
(1)慢查询介绍
MySQL的慢查询全名是慢查询日志，是MySQL提供的一种日志记录。慢查询日志会记录在MySQL中响应时间超过阈值的语句。MySQL数据库默认不启动慢查询日志，需要手动来设置这个参数。
如果不是调优需要的话，一般不建议启动该参数。因为开启慢查询日志会或多或少带来一定的性能影响，慢查询日志支持将日志记录写入文件和数据库表。
(2)慢查询参数
执行下面的语句
mysql> show variables like '%slow_query_log%';
+---------------------+------------------------------+
| Variable_name | Value |
+---------------------+------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/lib/mysql/test-slow.log |
+---------------------+------------------------------+
mysql> show variables like '%long_query%';
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+MySQL慢查询的相关参数解释：
一.slow_query_log：是否开启慢查询日志。
二.slow-query-log-file：慢查询日志存储路径。
三.long_query_time：慢查询阈值，查询时间多于设定阈值则记录日志。
(3)慢查询配置方式
一.默认情况下slow_query_log的值为OFF，表示慢查询日志是禁用的
mysql> show variables like '%slow_query_log%';
+---------------------+------------------------------+
| Variable_name | Value |
+---------------------+------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/lib/mysql/test-slow.log |
+---------------------+------------------------------+
二.可以通过设置slow_query_log的值来开启
mysql> set global slow_query_log=1;
三.set global slow_query_log=1开启慢查询日志当前生效重启失效
如果要永久生效，就必须修改配置文件my.cnf，其它系统变量也是如此。
-- 编辑配置
vim /etc/my.cnf
-- 添加如下内容
slow_query_log =1
slow_query_log_file=/var/lib/mysql/ruyuan-slow.log
-- 重启MySQL
service mysqld restart
mysql> show variables like '%slow_query%';
+---------------------+--------------------------------+
| Variable_name | Value |
+---------------------+--------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/lib/mysql/ruyuan-slow.log |
+---------------------+--------------------------------+
四. 开启了慢查询日志后，什么样的SQL才会记录到慢查询日志里
这个由参数long_query_time控制，默认long_query_time的值为10秒。
mysql> show variables like 'long_query_time';
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
mysql> set global long_query_time=1;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'long_query_time';
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
五.修改变量long_query_time，但查询值还是10
执行命令set global long_query_time=1后，需要重新连接或者打开新开会话才能看到修改值。
mysql> show variables like 'long_query_time';
+-----------------+----------+
| Variable_name | Value |
+-----------------+----------+
| long_query_time | 1.000000 |
+-----------------+----------+
六.log_output参数是指定日志的存储方式
log_output=FILE表示将日志存入文件，默认值是FILE。log_output=TABLE表示将日志存入数据库，这样日志信息就会被写入到mysql.slow_log表中。
MySQL数据库可以同时支持两种日志存储方式，配置的时候以逗号隔开即可，如：log_output=’FILE,TABLE’。
日志记录到系统的专用日志表中，要比记录到文件耗费更多的系统资源。因此如果启用慢查询日志+获得更高系统性能，则建议优先记录到文件。
mysql> SHOW VARIABLES LIKE '%log_output%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_output | FILE |
+---------------+-------+
七.开启系统变量让未使用索引的查询也被记录到慢查询日志中
这个系统变量就是log-queries-not-using-indexes，所以在进行调优时，可以开启这个选项。
mysql> show variables like 'log_queries_not_using_indexes';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | OFF |
+-------------------------------+-------+
mysql> set global log_queries_not_using_indexes=1;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'log_queries_not_using_indexes';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | ON |
+-------------------------------+-------+
(4)慢查询测试
一.执行test_index.sql脚本，监控慢查询日志内容
[root@localhost mysql]# tail -f /var/lib/mysql/test-slow.log
/usr/sbin/mysqld, Version: 5.7.30-log (MySQL Community Server (GPL)). started with:
Tcp port: 0 Unix socket: /var/lib/mysql/mysql.sock
Time Id Command Argument二. 执行下面的SQL，执行超时(超过1秒)我们去查看慢查询日志
SELECT * FROM test_index WHERE
hobby = '20009951' OR hobby = '10009931' OR hobby = '30009931'
OR dname = 'name4000' OR dname = 'name6600' ;
(5)慢日志内容
我们得到慢查询日志后，最重要的一步就是去分析这个日志。先来看慢日志里到底记录了哪些内容，如下是慢日志里其中一条记录，可以看到有时间戳、用户、查询时长及具体的SQL等信息。
Time Id Command Argument
# Time: 2022-02-23 T03:55:15. 336037Z
# User@Host: root[root] @ localhost [] Id: 6
# Query_time: 2.375219 Lock_time: 0.000137 Rows_sent: 3 Rows_examined: 5000000
use db4;
SET timestamp=1645588515;
SELECT * FROM test_index WHERE hobby = '20009961' OR hobby = '10009941' OR hobby = '30009961' OR dname = 'name4001' OR dname = 'name6601';Time：执行时间；
Users：用户信息；
Query_time：查询时长；
Lock_time：等待锁时长；
Rows_sent：结果行统计数量；
Rows_examined：扫描的行数；
6.慢查询SQL优化思路
(1)SQL性能下降的原因
(2)慢查询优化思路
(1)SQL性能下降的原因
导致SQL执行性能下降的原因可体现在以下两方面：
一.等待时间长
锁表导致查询一直处于等待状态。
二.执行时间长
查询语句没优化、索引失效、关联查询太多join、机器及参数没调优。
(2)慢查询优化思路
一.优先选择优化高并发执行的SQL
因为高并发的SQL出现问题带来后果更严重，比如下面两种情况：SQL1每小时执行10000次，每次20个IO，优化后每次18个IO，每小时节省2万次IO；SQL2每小时10次，每次20000个IO，每次优化减少2000个IO，每小时节省2万次IO。此时SQL2更难优化，SQL1更好优化。但是第一种属于高并发SQL，更急需优化，因为成本更低。
二.定位优化对象的性能瓶颈
在去优化SQL时，选择优化分方向有三个：
方向1：IO，数据访问消耗了太多时间，查看是否正确使用索引。
方向2：CPU，数据运算花费了太多时间，数据的运算分组、排序是不是有问题。
方向3：网络带宽，加大网络带宽。
三.明确优化目标
根据数据库当前状态、当前SQL的具体功能，来确定最好情况下消耗的资源和最差情况下消耗的资源。因为优化的结果只有一个，即给用户一个好的体验。
四.从explain执行计划入手
只有explain能告诉我们当前SQL的执行状态。
五.永远用小的结果集驱动大的结果集
小的数据集驱动大的数据集，减少内层表读取次数。
//类似于嵌套循环
for (int i = 0; i < 5; i++) {
for (int i = 0; i < 1000; i++) {
}
}
六.尽可能在索引中完成排序
排序操作用得比较多，所以order by后面的字段尽量使用上索引。因为索引本来就是排好序的，所以速度很快。没有索引的话，就需要从表中拿数据，在内存中进行排序。如果内存空间不够还会发生临时文件落盘操作。
七.只获取自己需要的列
不要使用select *，因为select * 很可能不使用索引，而且数据量过大。
八.只使用最有效的过滤条件
where后面的条件并非越多越好，应该用最短的路径访问到数据。
九.尽可能避免复杂的join和子查询
每条SQL的JOIN操作建议不要超过三张表。将复杂的SQL，拆分成多个小的SQL，单个表执行，然后对获取的结果在程序中进行封装。因为如果join占用的资源比较多，会导致其他进程等待时间变长。
十.合理设计并利用索引
也就是合理判断是否需要创建索引，以及合理选择合适索引。
(3)如何判定是否需要创建索引
一.频繁作为查询条件的字段应该创建索引
二.唯一性太差的字段不适合单独创建索引，即使它频繁作为查询条件
唯一性太差的字段主要是指哪些呢？如状态字段、类型字段等。这些字段中的数据可能总共就是那么几个几十个数值重复使用。当一条Query所返回的数据超过了全表的15%时，就不应该再使用索引扫描来完成这个Query了。
三.更新非常频繁的字段不适合创建索引
因为索引中的字段被更新时，不仅要更新表的数据，还要更新索引数据。
四.不会出现在WHERE子句中的字段不该创建索引
(4)如何选择合适索引
一.单键索引，尽量选择针对当前Query过滤性更好的索引。
二.联合索引，当前查询中过滤性最好的字段在索引字段顺序中排列靠前。
