MySQL深刻学习——第五章 慢查询&索引优化实战学习笔记
1、什么是慢查询？
慢查询日志，顾名思义，就是查询慢的日志，是指mysql记录全部执行超过long_query_time参数设定的时间阈值的SQL语句的日志。该日志能为SQL语句的优化带来很好的帮助。默认状况下，慢查询日志是关闭的，要使用慢查询日志功能，首先要开启慢查询日志功能。php
一、慢查询配置
1.一、慢查询基本配置html
slow_query_log 启动中止技术慢查询日志mysql
slow_query_log_file 指定慢查询日志得存储路径及文件（默认和数据文件放一块儿）算法
long_query_time 指定记录慢查询日志SQL执行时间得伐值（单位：秒，默认10秒）sql
log_queries_not_using_indexes 是否记录未使用索引的SQL数据库
log_output 日志存放的地方【TABLE】【FILE】【FILE,TABLE】json
配置了慢查询后，它会记录符合条件的SQL数组
包括：查询语句，数据修改语句，已经回滚得SQL缓存
实操：经过下面命令查看下上面的配置：服务器
show VARIABLES like '%slow_query_log%';
show VARIABLES like '%slow_query_log_file%';
show VARIABLES like '%long_query_time%'; -- 10秒 默认
show VARIABLES like '%log_queries_not_using_indexes%'; -- 默认off
show VARIABLES like 'log_output';
参数设置：
set global long_query_time=0; --- 默认10秒，这里为了演示方便设置为0
set GLOBAL slow_query_log=1; -- 开启慢查询日志
set global log_output='FILE,TABLE'; -- 项目开发中日志只能记录在日志文件中，不能记表中
设置完成后，查询一些列表能够发现慢查询的日志文件里面有数据了。
cat /data1/localhost-slow.log -- 多实例
cat /usr/local/mysql/data/localhost-slow.log -- 单实例
1.二、慢查询解读
从慢查询日志里面摘选一条慢查询日志，数据组成以下：
# User@Host: root[root] @ [192.168.30.199] Id: 21
# Query_time: 0.000078 Lock_time: 0.000000 Rows_sent: 4 Rows_examined: 4
SET timestamp=1561389688;
# administrator command: Init DB;
# Time: 2019-06-24T15:21:28.258812Z
# User@Host: root[root] @ [192.168.30.199] Id: 21
# Query_time: 0.000402 Lock_time: 0.000167 Rows_sent: 8 Rows_examined: 8
SET timestamp=1561389688;
SHOW COLUMNS FROM `hankin`.`t_user`;
慢查询格式显示：
第一行：用户名 、用户的IP信息、线程ID号
第二行：执行花费的时间【单位：毫秒】
第三行：执行得到锁的时间
第四行：得到的结果行数
第五行：扫描的数据行数
第六行：这SQL执行的具体时间
第七行：具体的SQL语句
二、慢查询分析
慢查询的日志记录很是多，要从里面找寻一条查询慢的日志并非很容易的事情，通常来讲都须要一些工具辅助才能快速定位到须要优化的SQL语句，下面介绍两个慢查询辅助工具
2.一、Mysqldumpslow
经常使用的慢查询日志分析工具，汇总除查询条件外其余彻底相同的SQL，并将分析结果按照参数中所指定的顺序输出。
语法：mysqldumpslow -s r -t 10 slocalhost-slow.log
-s order (c,t,l,r,at,al,ar)
c:总次数， t:总时间，l:锁的时间， r:总数据行
at,al,ar :t,l,r平均数 【例如：at = 总时间/总次数】
-t top 指定取前面几天做为结果输出
mysqldumpslow -s t -t 10
cat /data1/localhost-slow.log （多实例路劲）
cat /usr/local/mysql/data/localhost-slow.log
2.一、pt_query_digest
是用于分析mysql慢查询的一个工具，与mysqldumpshow工具相比，py-query_digest 工具的分析结果更具体，更完善。有时由于某些缘由如权限不足等，没法在服务器上记录查询，这样的限制咱们也经常碰到。
perl的模块：
yum install -y perl-CPAN perl-Time-HiRes
安装步骤：
方法一：rpm安装
cd /usr/local/src
wget percona.com/get/percona-toolkit.rpm
yum install -y percona-toolkit.rpm
工具安装目录在：/usr/bin
方法二：源码安装
cd /usr/local/src
wget percona.com/get/percona-toolkit.tar.gz
tar zxf percona-toolkit.tar.gz
cd percona-toolkit-2.2.19
perl Makefile.PL PREFIX=/usr/local/percona-toolkit
make && make install
工具安装目录在：/usr/local/percona-toolkit/bin
首先来看下一个命令：
yum -y install 'perl(Data::Dumper)';
yum -y install perl-Digest-MD5
yum -y install perl-DBI
yum -y install perl-DBD-MySQL
查看慢查询命令：
perl ./pt-query-digest --explain h=192.168.30.130,u=root,p=root /usr/local/mysql/data/localhost-slow.log
汇总信息【总的查询时间】、【总的锁定时间】、【总的获取数据量】、【扫描的数据量】、【查询大小】
Response: 总的响应时间。
time: 该查询在本次分析中总的时间占比。
calls: 执行次数，即本次分析总共有多少条这种类型的查询语句。
R/Call: 平均每次执行的响应时间。
Item : 查询对象
1）扩展阅读：
语法及重要选项
pt-query-digest [OPTIONS] [FILES] [DSN]
--create-review-table 当使用--review参数把分析结果输出到表中时，若是没有表就自动建立。
--create-history-table 当使用--history参数把分析结果输出到表中时，若是没有表就自动建立。
--filter 对输入的慢查询按指定的字符串进行匹配过滤后再进行分析
--limit 限制输出结果百分比或数量，默认值是20,即将最慢的20条语句输出，若是是50%则按总响应时间占比从大到小排序，输出到总和达到50%位置截止。
--host mysql服务器地址
--user mysql用户名
--password mysql用户密码
--history 将分析结果保存到表中，分析结果比较详细，下次再使用--history时，若是存在相同的语句，且查询所在的时间区间和历史表中的不一样，则会记录到数据表中，能够经过查询同一CHECKSUM来比较某类型查询的历史变化。
--review 将分析结果保存到表中，这个分析只是对查询条件进行参数化，一个类型的查询一条记录，比较简单。当下次使用--review时，若是存在相同的语句分析，就不会记录到数据表中。
--output 分析结果输出类型，值能够是report(标准分析报告)、slowlog(Mysql slow log)、json、json-anon，通常使用report，以便于阅读。
--since 从什么时间开始分析，值为字符串，能够是指定的某个”yyyy-mm-dd [hh:mm:ss]”格式的时间点，也能够是简单的一个时间值：s(秒)、h(小时)、m(分钟)、d(天)，如12h就表示从12小时前开始统计。
--until 截止时间，配合—since能够分析一段时间内的慢查询。
2）分析pt-query-digest输出结果
第一部分：整体统计结果
Overall：总共有多少条查询
Time range：查询执行的时间范围
unique：惟一查询数量，即对查询条件进行参数化之后，总共有多少个不一样的查询
total：总计 min：最小 max：最大 avg：平均
95%：把全部值从小到大排列，位置位于95%的那个数，这个数通常最具备参考价值
median：中位数，把全部值从小到大排列，位置位于中间那个数
# 该工具执行日志分析的用户时间，系统时间，物理内存占用大小，虚拟内存占用大小
# 340ms user time, 140ms system time, 23.99M rss, 203.11M vsz
# 工具执行时间
# Current date: Fri Nov 25 02:37:18 2016
# 运行分析工具的主机名
# Hostname: localhost.localdomain
# 被分析的文件名
# Files: slow.log
# 语句总数量，惟一的语句数量，QPS，并发数
# Overall: 2 total, 2 unique, 0.01 QPS, 0.01x concurrency
# 日志记录的时间范围
# Time range: 2016-11-22 06:06:18 to 06:11:40
# 属性 总计 最小 最大 平均 95% 标准 中等
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# 语句执行时间
# Exec time 3s 640ms 2s 1s 2s 999ms 1s
# 锁占用时间
# Lock time 1ms 0 1ms 723us 1ms 1ms 723us
# 发送到客户端的行数
# Rows sent 5 1 4 2.50 4 2.12 2.50
# select语句扫描行数
# Rows examine 186.17k 0 186.17k 93.09k 186.17k 131.64k 93.09k
# 查询的字符数
# Query size 455 15 440 227.50 440 300.52 227.50
第二部分：查询分组统计结果
Rank：全部语句的排名，默认按查询时间降序排列，经过--order-by指定
Query ID：语句的ID，（去掉多余空格和文本字符，计算hash值）
Response：总的响应时间
time：该查询在本次分析中总的时间占比
calls：执行次数，即本次分析总共有多少条这种类型的查询语句
R/Call：平均每次执行的响应时间
V/M：响应时间Variance-to-mean的比率
Item：查询对象
# Profile
# Rank Query ID Response time Calls R/Call V/M Item
# ==== ================== ============= ===== ====== ===== ===============
# 1 0xF9A57DD5A41825CA 2.0529 76.2% 1 2.0529 0.00 SELECT
# 2 0x4194D8F83F4F9365 0.6401 23.8% 1 0.6401 0.00 SELECT wx_member_base
第三部分：每一种查询的详细统计结果
由下面查询的详细统计结果，最上面的表格列出了执行次数、最大、最小、平均、95%等各项目的统计。
ID：查询的ID号，和上图的Query ID对应
Databases：数据库名
Users：各个用户执行的次数（占比）
Query_time distribution ：查询时间分布, 长短体现区间占比，本例中1s-10s之间查询数量是10s以上的两倍。
Tables：查询中涉及到的表
Explain：SQL语句
# Query 1: 0 QPS, 0x concurrency, ID 0xF9A57DD5A41825CA at byte 802
# This item is included in the report because it matches --limit.
# Scores: V/M = 0.00
# Time range: all events occurred at 2016-11-22 06:11:40
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 50 1
# Exec time 76 2s 2s 2s 2s 2s 0 2s
# Lock time 0 0 0 0 0 0 0 0
# Rows sent 20 1 1 1 1 1 0 1
# Rows examine 0 0 0 0 0 0 0 0
# Query size 3 15 15 15 15 15 0 15
# String:
# Databases test
# Hosts 192.168.8.1
# Users mysql
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s ################################################################
# 10s+
# EXPLAIN /*!50100 PARTITIONS*/
select sleep(2)\G
2、索引
一、生活中的索引
MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。能够获得索引的本质：索引是数据结构。
上面的理解比较抽象，举一个例子，平时看任何一本书，首先看到的都是目录，经过目录去查询书籍里面的内容会很是的迅速。
另外经过目录（索引），能够快速查询到目录里面的内容，它能高效获取数据，经过这个简单的案例能够理解因此就是高效获取数据的数据结构。
再来看一个发杂的状况，
咱们要去图书馆找一本书，这图书馆的书确定不是线性存放的，它对不一样的书籍内容进行了分类存放，整索引因为一个个节点组成，根节点有中间节点，中间节点下面又由子节点，最后一层是叶子节点。
可见，整个索引结构是一棵倒挂着的树，其实它就是一种数据结构，这种数据结构比前面讲到的线性目录更好的增长了查询的速度。
二、MySql中的索引
MySql中的索引其实也是这么一回事，咱们能够在数据库中创建一系列的索引，好比建立主键的时候默认会建立主键索引，上图是一种BTREE的索引，每个节点都是主键的ID。当咱们经过ID来查询内容的时候，首先去查索引库，在到索引库后能快速的定位索引的具体位置。
三、谈下B+Tree
要谈B+TREE说白了仍是Tree,但谈这些以前还要从基础开始讲起
3.一、二分查找
二分查找法（binary search） 也称为折半查找法，用来查找一组有序的记录数组中的某一记录。
其基本思想是：将记录按有序化（递增或递减）排列，在查找过程当中采用跳跃式方式查找，即先以有序数列的中点位置做为比较对象，若是要找的元素值小于该中点元素，则将待查序列缩小为左半部分，不然为右半部分。经过一次比较，将查找区间缩小一半。
# 给出一个例子，注意该例子已是升序排序的，且查找 数字 48
数据：5， 10， 19， 21， 31， 37， 42， 48， 50， 52
下标：0， 1， 2， 3， 4， 5， 6， 7， 8， 9
步骤一：设 low 为下标最小值 0 ， high 为下标最大值 9 ;
步骤二：经过 low 和 high 获得 mid ，mid=（low + high） / 2，初始时 mid 为下标 4 (也能够=5，看具体算法实现)；
步骤三 ： mid=4 对应的数据值是31，31 < 48（咱们要找的数字）；
步骤四：经过二分查找的思路，将low设置为31对应的下标 4 ，high 保持不变为9，此时mid为 6 ；
步骤五 ：mid=6 对应的数据值是42，42 < 48（咱们要找的数字）；
步骤六：经过二分查找的思路，将low设置为42对应的下标6 ，high保持不变为9，此时mid为7 ；
步骤七 ：mid=7对应的数据值是48，48 == 48（咱们要找的数字），查找结束；
经过3次 二分查找 就找到了咱们所要的数字，而顺序查找需8
3.二、二叉树(Binary Tree)
每一个节点至多只有二棵子树；
• 二叉树的子树有左右之分，次序不能颠倒；
• 一棵深度为k，且有 个节点，称为满二叉树(Full Tree)；
• 一棵深度为k，且root到k-1层的节点树都达到最大，第k层的全部节点都 连续集中 在最左边，此时为彻底二叉树（Complete Tree）
3.三、平衡二叉树（AVL-树）
- 左子树和右子树都是平衡二叉树；
- 左子树和右子树的高度差绝对值不超过1；
1）平衡二叉树的遍历
- 前序 ：6 ,3, 2, 5,7, 8（ROOT节点在开头, 中 -左-右 顺序）
- 中序 ：2, 3, 5, 6,7, 8（中序遍历即为升序，左- 中 -右 顺序）
- 后序 ：2, 5, 3, 8,7, 6 （ROOT节点在结尾，左-右- 中 顺序）
2）平衡二叉树的旋转
四、B+树须要经过旋转（左旋，右旋）来维护平衡二叉树的平衡，在添加和删除的时候须要有额外的开销。
4.一、B+树的定义
数据只存储在叶子节点上，非叶子节点只保存索引信息；
非叶子节点（索引节点）存储的只是一个Flag，不保存实际数据记录；
索引节点指示该节点的左子树比这个Flag小，而右子树大于等于这个Flag 叶子节点自己按照数据的升序排序进行连接(串联起来)；
叶子节点中的数据在 物理存储上是无序 的，仅仅是在 逻辑上有序 （经过指针串在一块儿）；
4.二、B+树的做用
在块设备上，经过B+树能够有效的存储数据；
全部记录都存储在叶子节点上，非叶子(non-leaf)存储索引(keys)信息；
B+树含有很是高的扇出（fanout），一般超过100，在查找一个记录时，能够有效的减小IO操做；
4.三、B+树的扇出(fan out)
- 该 B+ 树高度为 2
- 每叶子页（LeafPage）4条记录
- 扇出数为5
- 叶子节点(LeafPage)由小到大（有序）串联在一块儿
扇出：是每一个索引节点(Non-LeafPage)指向每一个叶子节点(LeafPage)的指针
扇出数 = 索引节点(Non-LeafPage)可存储的最大关键字个数 + 1
图例中的索引节点(Non-LeafPage)最大能够存放4个关键字，但实际使用了3个；
4.四、B+树的插入操做
• B+树的插入
B+树的插入必须保证插入后叶子节点中的记录依然排序。
问题：1 插入28：
结果：由于叶子节点未满，能够插入成功，总扇出数不变，顺序也保持不变。
问题2：插入70：
结果：因为叶子节点不能知足直接插入，须要裂变，多出一个扇出60，对应叶子节点变化如上图。
问题3：插入95：
更多细节能够参考：https://blog.csdn.net/shenchaohao12321/article/details/83243314
五、索引的分类
普通索引：即一个索引只包含单个列，一个表能够有多个单列索引
惟一索引：索引列的值必须惟一，但容许有空值
复合索引：即一个索引包含多个列
聚簇索引(汇集索引)：并非一种单独的索引类型，而是一种数据存储方式。具体细节取决于不一样的实现，InnoDB的聚簇索引其实就是在同一个结构中保存了B-Tree索引(技术上来讲是B+Tree)和数据行。
非聚簇索引：不是聚簇索引，就是非聚簇索引
六、基础语法
查看索引：
SHOW INDEX FROM table_name\G
建立索引：
CREATE [UNIQUE ] INDEX indexName ON mytable(columnname(length)); ALTER TABLE 表名 ADD [UNIQUE ] INDEX [indexName] ON (columnname(length))
删除索引：
DROP INDEX [indexName] ON mytable;
3、执行计划
什么是执行计划
使用EXPLAIN关键字能够模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈。
执行计划的做用：
- 表的读取顺序
- 数据读取操做的操做类型
- 哪些索引可使用
- 哪些索引被实际使用
- 表之间的引用
- 每张表有多少行被优化器查询
以上的这些做用会在执行计划详解里面介绍到，在这里不作解释。
执行计划的语法：
执行计划的语法其实很是简单： 在SQL查询的前面加上EXPLAIN关键字就行。
好比：EXPLAIN select * from table1，重点的就是EXPLAIN后面你要分析的SQL语句。
执行计划详解
经过EXPLAIN关键分析的结果由如下列组成，接下来挨个分析每个列：
id | select_type | table| partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra
一、ID列
ID列：描述select查询的序列号,包含一组数字，表示查询中执行select子句或操做表的顺序
根据ID的数值结果能够分红一下三种状况
- id相同：执行顺序由上至下
- id不一样：若是是子查询，id的序号会递增，id值越大优先级越高，越先被执行
- id相同不一样：同时存在
分别举例来看：
1）Id相同
如上图所示，ID列的值全为1，表明执行的容许从t1开始加载，依次为t3与t2
EXPLAIN select t2.* from t1,t2,t3 where t1.id = t2.id and t1.id = t3.id and t1.other_column = '';
2）Id不一样
若是是子查询，id的序号会递增，id值越大优先级越高，越先被执行
EXPLAIN select t2.* from t2 where id = ( select id from t1 where id = (select t3.id from t3 where t3.other_column=''));
3）Id相同又不一样
id若是相同，能够认为是一组，从上往下顺序执行；
在全部组中，id值越大，优先级越高，越先执行
EXPLAIN select t2.* from (select t3.id from t3 where t3.other_column = '' ) s1 ,t2 where s1.id = t2.id
二、select_type列
Select_type：查询的类型，主要是用于区别普通查询、联合查询、子查询等的复杂查询
类型以下：
1）SIMPLE类型
EXPLAIN select * from t1;
简单的 select 查询，查询中不包含子查询或者UNION
2）PRIMARY与SUBQUERY类型
PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记为
SUBQUERY：在SELECT或WHERE列表中包含了子查询
EXPLAIN select t1.*,(select t2.id from t2 where t2.id = 1 ) from t1
3）DERIVED类型
在FROM列表中包含的子查询被标记为DERIVED(衍生)，MySQL会递归执行这些子查询, 把结果放在临时表里。
select t1.* from t1 ,(select t2.* from t2 where t2.id = 1 ) s2 where t1.id = s2.id;
4）UNION RESULT 与UNION类型
UNION：若第二个SELECT出如今UNION以后，则被标记为UNION；
UNION RESULT：从UNION表获取结果的SELECT
# UNION RESULT ,UNION
EXPLAIN select * from staffs where name='July' UNION select * from staffs where name = 'z3';
三、table列
显示这一行的数据是关于哪张表的
四、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。
1）System与const访问类型
System：表只有一行记录(等于系统表)，这是const类型的特列，平时不会出现，这个也能够忽略不计
Const：表示经过索引一次就找到了。
const用于比较primary key或者unique索引。由于只匹配一行数据，因此很快
如将主键置于where列表中，MySQL就能将该查询转换为一个常量
EXPLAIN SELECT * from (select * from t2 where id = 1) d1;
2）eq_ref访问类型
惟一性索引扫描，对于每一个索引键，表中只有一条记录与之匹配。常见于主键或惟一索引扫描
EXPLAIN SELECT * from t1,t2 where t1.id = t2.id;
3）Ref访问类型
非惟一性索引扫描，返回匹配某个单独值的全部行。
本质上也是一种索引访问，它返回全部匹配某个单独值的行，然而，它可能会找到多个符合条件的行，因此他应该属于查找和扫描的混合体。
EXPLAIN select count(DISTINCT col1) from t1 where col1 = 'ac';
或者EXPLAIN select col1 from t1 where col1 = 'ac';
4）Range访问类型
只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪一个索引
通常就是在你的where语句中出现了between、<、>、in等的查询
这种范围扫描索引扫描比全表扫描要好，由于它只须要开始于索引的某一点，而结束语另外一点，不用扫描所有索引。
EXPLAIN select * from t1 where id BETWEEN 30 and 60;
EXPLAIN select * from t1 where id in(1,2);
5）Index访问类型
当查询的结果全为索引列的时候，虽然也是所有扫描，可是只查询的索引库，而没有去查询数据。
EXPLAIN select c2 from testdemo
6）All访问类型
Full Table Scan，将遍历全表以找到匹配的行
五、possible_keys 与Key列
possible_keys:可能使用的key
Key:实际使用的索引。若是为NULL，则没有使用索引
查询中若使用了覆盖索引，则该索引和查询的select字段重叠
这里的覆盖索引很是重要，后面会单独的来说
EXPLAIN select col1,col2 from t1;
其中key和possible_keys均可以出现null的状况（结婚邀请朋友的例子）。
六、key_len列
desc select * from ta where col1 ='ab';
desc select * from ta where col1 ='ab' and col2 = 'ac';
Key_len表示索引中使用的字节数，可经过该列计算查询中使用的索引的长度。在不损失精确性的状况下，长度越短越好。
key_len显示的值为索引字段的最大可能长度，并不是实际使用长度，即key_len是根据表定义计算而得，不是经过表内检索出的。
注意：
根据底层使用的不通存储引擎，受影响的行数这个指标多是一个估计值，也多是一个精确值。及时受影响的行数是一个估计值（例如当使用InnoDB存储引擎管理表存储时），一般秦光霞这个估计值也足以使优化器作出一个有充分依据的决定。
- key_len表示索引使用的字节数，
- 根据这个值，就能够判断索引使用状况，特别是在组合索引的时候，判断全部的索引字段是否都被查询用到。
- char和varchar跟字符编码也有密切的联系,
- latin1占用1个字节，gbk占用2个字节，utf8占用3个字节。（不一样字符编码占用的存储空间不一样）
6.一、字符类型
以上这个表列出了全部字符类型，但真正建全部的类型经常使用状况只是CHAR、VARCHAR
1）字符类型-索引字段为char类型+不可为Null时
CREATE TABLE `s1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` char(10) NOT NULL, `addr` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; explain select * from s1 where name='enjoy';
name这一列为char(10),字符集为utf-8占用3个字节
Keylen=10*3
2）字符类型-索引字段为char类型+容许为Null时
CREATE TABLE `s2` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` char(10) DEFAULT NULL, `addr` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; explain select * from s2 where name='enjoyedu';
name这一列为char(10),字符集为utf-8占用3个字节,外加须要存入一个null值
Keylen=10*3+1(null) 结果为31
3）索引字段为varchar类型+不可为Null时
CREATE TABLE `s3` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(10) NOT NULL, `addr` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; explain select * from s3 where name='enjoyeud';
Keylen=varchar(n)变长字段+不容许Null=n*(utf8=3,gbk=2,latin1=1)+2
4）索引字段为varchar类型+容许为Null时
CREATE TABLE `s3` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(10) NOT NULL, `addr` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; explain select * from s3 where name='enjoyeud';
Keylen=varchar(n)变长字段+容许Null=n*(utf8=3,gbk=2,latin1=1)+1(NULL)+2
6.二、数值类型
CREATE TABLE `numberKeyLen ` ( `c0` int(255) NOT NULL , `c1` tinyint(255) NULL DEFAULT NULL , `c2` smallint(255) NULL DEFAULT NULL , `c3` mediumint(255) NULL DEFAULT NULL , `c4` int(255) NULL DEFAULT NULL , `c5` bigint(255) NULL DEFAULT NULL , `c6` float(255,0) NULL DEFAULT NULL , `c7` double(255,0) NULL DEFAULT NULL , PRIMARY KEY (`c0`), INDEX `index_tinyint` (`c1`) USING BTREE , INDEX `index_smallint` (`c2`) USING BTREE , INDEX `index_mediumint` (`c3`) USING BTREE , INDEX `index_int` (`c4`) USING BTREE , INDEX `index_bigint` (`c5`) USING BTREE , INDEX `index_float` (`c6`) USING BTREE , INDEX `index_double` (`c7`) USING BTREE )ENGINE=InnoDB DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci ROW_FORMAT=COMPACT;
EXPLAIN select * from numberKeyLen where c1=1 EXPLAIN select * from numberKeyLen where c2=1 EXPLAIN select * from numberKeyLen where c3=1 EXPLAIN select * from numberKeyLen where c4=1 EXPLAIN select * from numberKeyLen where c5=1 EXPLAIN select * from numberKeyLen where c6=1 EXPLAIN select * from numberKeyLen where c7=1
6.三、日期和时间
datetime类型在5.6中字段长度是5个字节
datetime类型在5.5中字段长度是8个字节
CREATE TABLE `datatimekeylen ` ( `c1` date NULL DEFAULT NULL , `c2` time NULL DEFAULT NULL , `c3` year NULL DEFAULT NULL , `c4` datetime NULL DEFAULT NULL , `c5` timestamp NULL DEFAULT NULL , INDEX `index_date` (`c1`) USING BTREE , INDEX `index_time` (`c2`) USING BTREE , INDEX `index_year` (`c3`) USING BTREE , INDEX `index_datetime` (`c4`) USING BTREE , INDEX `index_timestamp` (`c5`) USING BTREE )ENGINE=InnoDB DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci ROW_FORMAT=COMPACT; EXPLAIN SELECT * from datatimekeylen where c1 = 1; EXPLAIN SELECT * from datatimekeylen where c2 = 1; EXPLAIN SELECT * from datatimekeylen where c3 = 1; EXPLAIN SELECT * from datatimekeylen where c4 = 1; EXPLAIN SELECT * from datatimekeylen where c5 = 1;
总结
字符类型：
变长字段须要额外的2个字节（VARCHAR值保存时只保存须要的字符数，另加一个字节来记录长度(若是列声明的长度超过255，则使用两个字节)，因此VARCAHR索引长度计算时候要加2），固定长度字段不须要额外的字节。
而NULL都须要1个字节的额外空间,因此索引字段最好不要为NULL，由于NULL让统计更加复杂而且须要额外的存储空间。
复合索引有最左前缀的特性，若是复合索引能所有使用上，则是复合索引字段的索引长度之和，这也能够用来断定复合索引是否部分使用，仍是所有使用。
整数/浮点数/时间类型的索引长度
NOT NULL=字段自己的字段长度
NULL=字段自己的字段长度+1(由于须要有是否为空的标记，这个标记须要占用1个字节)
datetime类型在5.6中字段长度是5个字节，datetime类型在5.5中字段长度是8个字节
七、Ref列
显示索引的哪一列被使用了，若是可能的话，是一个常数。哪些列或常量被用于查找索引列上的值
EXPLAIN select * from s1 ,s2 where s1.id = s2.id and s1.name = 'enjoy'
由key_len可知t1表的idx_col1_col2被充分使用，col1匹配t2表的col1，col2匹配了一个常量，即 'ac'
其中 【shared.t2.col1】 为 【数据库.表.列】
八、Rows列
根据表统计信息及索引选用状况，大体估算出找到所需的记录所须要读取的行数
九、Extra列
包含不适合在其余列中显示但十分重要的额外信息
1）Using filesort
说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。
MySQL中没法利用索引完成的排序操做称为“文件排序”，当发现有Using filesort 后，实际上就是发现了能够优化的地方。
上图实际上是一种索引失效的状况，后面会讲，能够看出查询中用到了个联合索引，索引分别为col1,col2,col3
当我排序新增了个col2，发现using filesort 就没有了
EXPLAIN select col1 from t1 where col1='ac' order by col3;
EXPLAIN select col1 from t1 where col1='ac' order by col2,col3;
2）Using temporary
使了用临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by。
尤为发如今执行计划里面有using filesort并且还有Using temporary的时候，特别须要注意
EXPLAIN select col1 from t1 where col1 in('ac','ab','aa') GROUP BY col2;
EXPLAIN select col1 from t1 where col1 in('ac','ab','aa') GROUP BY col1,col2;
3）Using index
表示相应的select操做中使用了覆盖索引(Covering Index)，避免访问了表的数据行，效率不错！
若是同时出现using where，代表索引被用来执行索引键值的查找;
若是没有同时出现using where，代表索引用来读取数据而非执行查找动做
EXPLAIN select col2 from t1 where col1 = 'ab';
EXPLAIN select col2 from t1 ;
覆盖索引：
覆盖索引（Covering Index），一说为索引覆盖。
理解方式一：就是select的数据列只用从索引中就可以取得，没必要读取数据行，MySQL能够利用索引返回select列表中的字段，而没必要根据索引再次读取数据文件,换句话说查询列要被所建的索引覆盖。
理解方式二：索引是高效找到行的一个方法，可是通常数据库也能使用索引找到一个列的数据，所以它没必要读取整个行。毕竟索引叶子节点存储了它们索引的数据;当能经过读取索引就能够获得想要的数据，那就不须要读取行了。一个索引包含了(或覆盖了)知足查询结果的数据就叫作覆盖索引
注意：
若是要使用覆盖索引，必定要注意select列表中只取出须要的列，不可select *，
由于若是将全部字段一块儿作索引会致使索引文件过大，查询性能降低。
因此，千万不能为了查询而在全部列上都创建索引，会严重影响修改维护的性能。
4）Using where 与 using join buffer
Using where 代表使用了where过滤
using join buffer 使用了链接缓存：
show VARIABLES like '%join_buffer_size%'
EXPLAIN select * from t1 JOIN t2 on t1.other_column = t2.other_column;
5）impossible where
where子句的值老是false，不能用来获取任何元组
EXPLAIN select * from t1 where 1=2;
EXPLAIN select * from t1 where t1.other_column ='enjoy' and t1.other_column = 'edu';