慢 SQL
性能下降、 SQL 慢、执行时间长、等待时间长的原因分析
- 查询语句写的烂
- 索引失效:
- 单值索引:在user表中给name属性建个索引,create index idx_user_name on user(name)
- 复合索引:在user表中给name、email属性建个索引,create index idx_user_nameEmail on user(name,email)
- 关联查询太多join(设计缺陷或不得已的需求)
- 服务器调优及各个参数设置(缓冲、线程数等)
join 查询
常见的 JOIN 查询图
建表 SQL
1 | mysql复制代码CREATE TABLE tbl_dept( |
- tbl_dept 表结构
1 | mysql复制代码mysql> select * from tbl_dept; |
- tbl_emp 表结构
1 | mysql复制代码mysql> select * from tbl_emp; |
笛卡尔积
- tbl_emp 表和 tbl_dept 表的笛卡尔乘积:
select * from tbl_emp, tbl_dept;
- tbl_emp 表和 tbl_dept 表的笛卡尔乘积:
- 其结果集的个数为:5 * 8 = 40
1 | mysql复制代码mysql> select * from tbl_emp, tbl_dept; |
内连接(inner join)
- tbl_emp 表和 tbl_dept 的交集部分(公共部分)
select * from tbl_emp e inner join tbl_dept d on e.deptId = d.id;
1 | mysql复制代码mysql> select * from tbl_emp e inner join tbl_dept d on e.deptId = d.id; |
左连接(left join)
- tbl_emp 与 tbl_dept 的公共部分 + tbl_emp 表的独有部分
- left join:取左表独有部分 + 两表公共部分
select * from tbl_emp e left join tbl_dept d on e.deptId = d.id;
1 | mysql复制代码mysql> select * from tbl_emp e left join tbl_dept d on e.deptId = d.id; |
右连接(right join)
- tbl_emp 与 tbl_dept 的公共部分 + tbl_dept表的独有部分
- right join:取右表独有部分 + 两表公共部分
select * from tbl_emp e right join tbl_dept d on e.deptId = d.id;
1 | mysql复制代码mysql> select * from tbl_emp e right join tbl_dept d on e.deptId = d.id; |
left join without common part
- tbl_emp 表的独有部分:将 left join 结果集中的两表公共部分去掉即可:where d.id is null
select * from tbl_emp e left join tbl_dept d on e.deptId = d.id where d.id is null;
1 | mysql复制代码mysql> select * from tbl_emp e left join tbl_dept d on e.deptId = d.id where d.id is null; |
right join without common part
- tbl_dept表的独有部分:将 right join 结果集中的两表公共部分去掉即可:where e.id is null
select * from tbl_emp e right join tbl_dept d on e.deptId = d.id where e.id is null;
1 | mysql复制代码mysql> select * from tbl_emp e right join tbl_dept d on e.deptId = d.id where e.id is null; |
full join
- mysql 不支持 full join ,但是我们可以通过骚操作实现 full join ,union 关键字用于连接结果集,并且自动去重
- tbl_emp 与 tbl_dept 的公共部分 + tbl_emp 表的独有部分 + tbl_dept表的独有部分:将 left join 的结果集和 right join 的结果集使用 union 合并即可
select * from tbl_emp e left join tbl_dept d on e.deptId = d.id union select * from tbl_emp e right join tbl_dept d on e.deptId = d.id;
1 | mysql复制代码mysql> select * from tbl_emp e left join tbl_dept d on e.deptId = d.id |
full join without common part
- tbl_emp 表的独有部分 + tbl_dept表的独有部分
select * from tbl_emp e left join tbl_dept d on e.deptId = d.id where d.id is null union select * from tbl_emp e right join tbl_dept d on e.deptId = d.id where e.id is null;
1 | mysql复制代码mysql> select * from tbl_emp e left join tbl_dept d on e.deptId = d.id where d.id is null |
索引
索引简介
索引是个什么东东?
- MySQL官方对索引的定义为:索引(Index)是帮助MySQL高效获取数据的数据结构。可以得到索引的本质:索引是数据结构
- 你可以简单理解为”排好序的快速查找数据结构”,即索引 = 排序 + 查找
- 一般来说索引本身占用内存空间也很大,不可能全部存储在内存中,因此索引往往以文件形式存储在硬盘上
- 我们平时所说的索引,如果没有特别指明,都是指B树(多路搜索树,并不一定是二叉树)结构组织的索引。
- 聚集索引,次要索引,覆盖索引,复合索引,前缀索引,唯一索引默认都是使用B+树索引,统称索引。当然,除了B+树这种类型的索引之外,还有哈希索引(hash index)等。
索引原理
将索引理解为**“排好序的快速查找数据结构”**
- 在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构上实现高级查找算法。这种数据结构,就是索引。
- 下图就是一种可能的索引方式示例:
- 左边是数据表,一共有两列七条记录,最左边的十六进制数字是数据记录的物理地址
- 为了加快col2的查找,可以维护一个右边所示的二叉查找树,每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针,这样就可以运用二叉查找在一定的复杂度内获取到相应数据,从而快速的检索出符合条件的记录。
索引优劣势
索引的优势
- 类似大学图书馆的书目索引,提高数据检索效率,降低数据库的IO成本
- 通过索引列对数据进行排序,降低数据排序成本,降低了CPU的消耗
索引的劣势
- 实际上索引也是一张表,该表保存了主键和索引字段,并指向实体表的记录,所以索引列也是要占用空间的
- 虽然索引大大提高了查询速度,同时却会降低更新表的速度,如果对表INSERT,UPDATE和DELETE。因为更新表时,MySQL不仅要不存数据,还要保存一下索引文件每次更新添加了索引列的字段,都会调整因为更新所带来的键值变化后的索引信息
- 索引只是提高效率的一个因素,如果你的MySQL有大数据量的表,就需要花时间研究建立优秀的索引,或优化查询语句
MySQL 索引分类
mysql 索引分类
- 普通索引:是最基本的索引,它没有任何限制,即一个索引只包含单个列,一个表可以有多个单列索引;建议一张表索引不要超过5个,优先考虑复合索引
- 唯一索引:与前面的普通索引类似,不同的就是:索引列的值必须唯一,但允许有空值。如果是组合索引,则列值的组合必须唯一
- 主键索引:是一种特殊的唯一索引,一个表只能有一个主键,不允许有空值。一般是在建表的时候同时创建主键索引:
- 复合索引:指多个字段上创建的索引,只有在查询条件中使用了创建索引时的第一个字段,索引才会被使用。使用组合索引时遵循最左前缀集合
- 全文索引:主要用来查找文本中的关键字,而不是直接与索引中的值相比较。fulltext索引跟其它索引大不相同,它更像是一个搜索引擎,而不是简单的where语句的参数匹配
MySQL 索引语法
建立索引的 SQL 语句
创建索引:
- 如果是CHAR和VARCHAR类型,length可以小于字段实际长度;
- 如果是BLOB和TEXT类型,必须指定length。
1 | mysql复制代码CREATE [UNIQUE] INDEX indexName ON mytable(columnname(length)); |
删除索引
1 | mysql复制代码DROP INDEX [indexName] ON mytable; |
查看索引(\G
表示将查询到的横向表格纵向输出,方便阅读)
1 | mysql复制代码SHOW INDEX FROM table_name\G; |
使用 ALTER 命令,有四种方式来添加数据表的索引:
ALTER TABLE tbl_name ADD PRIMARY KEY(column_list)
:该语句添加一个主键,这意味着索引值必须是唯一的,且不能为NULL。ALTER TABLE tbl_name ADD UNIQUE index_name(column_list)
:这条语句创建索引的值必须是唯一的(除了NULL外,NULL可能会出现多次)。ALTER TABLE tbl_name ADD INDEX index_name(column_list)
:.添加普通索引,索引值可出现多次。ALTER TABLE tbl_name ADD FULLTEXT index_name(column_list)
:该语句指定了索引为FULLTEXT,用于全文索引。
带你看看 mysql 索引:Index_type 为 BTREE
1 | mysql复制代码mysql> show index from tbl_emp; |
MySQL 索引结构
Btree 索引
Btree 索引搜索过程
【初始化介绍】
- 一颗 b 树, 浅蓝色的块我们称之为一个磁盘块, 可以看到每个磁盘块包含几个数据项(深蓝色所示) 和指针(黄色所示)
- 如磁盘块 1 包含数据项 17 和 35, 包含指针 P1、 P2、 P3
- P1 表示小于 17 的磁盘块, P2 表示在 17 和 35 之间的磁盘块, P3 表示大于 35 的磁盘块
- 真实的数据存在于叶子节点和非叶子节点中
【查找过程】
- 如果要查找数据项 29, 那么首先会把磁盘块 1 由磁盘加载到内存, 此时发生一次 IO, 在内存中用二分查找确定 29在 17 和 35 之间, 锁定磁盘块 1 的 P2 指针, 内存时间因为非常短(相比磁盘的 IO) 可以忽略不计
- 通过磁盘块 1的 P2 指针的磁盘地址把磁盘块 3 由磁盘加载到内存, 发生第二次 IO, 29 在 26 和 30 之间, 锁定磁盘块 3 的 P2 指针
- 通过指针加载磁盘块 8 到内存, 发生第三次 IO, 同时内存中做二分查找找到 29, 结束查询, 总计三次 IO。
B+tree 索引
B+tree 索引搜索过程
【B+Tree 与 BTree 的区别】
B-树的关键字(数据项)和记录是放在一起的; B+树的非叶子节点中只有关键字和指向下一个节点的索引, 记录只放在叶子节点中。
【B+Tree 与 BTree 的查找过程】
- 在 B 树中, 越靠近根节点的记录查找时间越快, 只要找到关键字即可确定记录的存在; 而 B+ 树中每个记录的查找时间基本是一样的, 都需要从根节点走到叶子节点, 而且在叶子节点中还要再比较关键字。
- 从这个角度看 B 树的性能好像要比 B+ 树好, 而在实际应用中却是 B+ 树的性能要好些。 因为 B+ 树的非叶子节点不存放实际的数据,这样每个节点可容纳的元素个数比 B 树多, 树高比 B 树小, 这样带来的好处是减少磁盘访问次数。
- 尽管 B+ 树找到一个记录所需的比较次数要比 B 树多, 但是一次磁盘访问的时间相当于成百上千次内存比较的时间, 因此实际中B+ 树的性能可能还会好些, 而且 B+树的叶子节点使用指针连接在一起, 方便顺序遍历(范围搜索), 这也是很多数据库和文件系统使用 B+树的缘故。
【性能提升】
真实的情况是, 3 层的 B+ 树可以表示上百万的数据, 如果上百万的数据查找只需要三次 IO, 性能提高将是巨大的,如果没有索引, 每个数据项都要发生一次 IO, 那么总共需要百万次的 IO, 显然成本非常非常高。
【思考: 为什么说 B+树比 B-树更适合实际应用中操作系统的文件索引和数据库索引?】
- B+树的磁盘读写代价更低:B+树的内部结点并没有指向关键字具体信息的指针。 因此其内部结点相对 B 树更小。 如果把所有同一内部结点的关键字存放在同一盘块中, 那么盘块所能容纳的关键字数量也越多。 一次性读入内存中的需要查找的关键字也就越多。 相对来说 IO 读写次数也就降低了。
- B+树的查询效率更加稳定:由于非终结点并不是最终指向文件内容的结点, 而只是叶子结点中关键字的索引。 所以任何关键字的查找必须走一条从根结点到叶子结点的路。 所有关键字查询的路径长度相同, 导致每一个数据的查询效率相当。
非聚集索引(MyISAM)
- B+树叶子节点只会存储数据行(数据文件)的指针,简单来说数据和索引不在一起,就是非聚集索引(InnoDB中的聚集索引:主键作为key,数据行作为value粗一起存储在一个叶子节点中)
- 非聚集索引包括主键索引和辅助索引。
1.主键索引
这里设表有三列,假设我们在以Col1为主键,如下图所示,可以看出MyISAM的索引文件仅仅保存数据记录的地址。
2.辅助索引(次要索引)
在MyISAM中,主索引和辅助索引(Secondary key)在结构上没有任何区别,只是主索引要求key是唯一的,而辅助索引的key可以重复,如果我们在Col2上建立一个辅助索引,则此辅助索引的结构如下图所示
同样也是一颗B+Tree,data域保存数据记录的地址,因此,MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引,如果指定的key存在,则取出其data域的值,然后以data域的值为地址,读取相应的数据记录。
聚集索引(InnoDB)
- 主键索引(聚集索引)的叶子节点会存储数据行,也就是说数据和索引是在一起的,相当于key是主键索引,value就是对应的记录行,这就是聚集索引。
- 辅助索引只会存储索引与主键索引的映射关系,相当于key是索引,value就是对应的主键,找到对应的主键索引之后,接着再通过主键索引找到对应的数据行,这个过程也叫做回表,但是在覆盖索引的情况下不需要回表操作,因为覆盖索引所查询的列都存在于组成覆盖索引的列中,只需要通过覆盖索引查找数据返回即可。
- 如果没有主键,则使用唯一索引建立聚集索引;如果没有唯一索引,MySQL会按照一定的规则创建聚集索引(一般会通过创建隐藏列建立唯一索引)
主键索引
InnoDB要求表必须有主键(MyISAM可以没有),如果没有显式指定,则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键,如果不存在这种列,则MySQL自动为InnoDB表生成一个隐含字段作为主键,类型为长整型。
上图是InnoDB主索引(同时也是数据文件)的示意图,可以看到叶子节点包含了完整的数据记录,这种索引叫做聚集索引,因为InnoDB的数据文件本身也是按照主键聚集的。
辅助索引(次要索引)
与MyISAM不同的是InnoDB的辅助索引的data域存储的是对应的主键列的值而不是数据行的地址,换句话说,InnoDB的所有辅助索引都引用主键作为data域。
如上图所示,name列作为辅助索引,首先通过该索引找到对应的主键值,接着再通过索引树查找主键索引,找到对应的记录行,如下图所示,聚集索引这种实现使得按主键的搜索十分高效,但是辅助索引搜索需要检索两遍索引,即首先检索辅助索引获得主键,然后用主键到主键索引中检索获得记录。
为什么不建议使用过长的字段作为主键?
因为所有辅助索引都引用主键,过长的主键会让辅助索引变得很大。同时,请尽量在InnoDB上采用自增字段做表的主键。
为什么使用组合索引?
为了节省MySQL索引存储空间以及提升搜索性能,可建立组合索引(能使用组合索引就不使用单列索引)。
何时需要建索引
哪些情况下适合建立索引
- 主键自动建立唯一索引
- 频繁作为查询的条件的字段应该创建索引
- 查询中与其他表关联的字段,外键关系建立索引
- 频繁更新的字段不适合创建索引
- Where 条件里用不到的字段不创建索引
- 单列/组合索引的选择问题,Who?(在高并发下倾向创建组合索引)
- 查询中排序的字段,排序字段若通过索引去访问将大大提高排序的速度
- 查询中统计或者分组字段
哪些情况不要创建索引
- 表记录太少
- 经常增删改的表
- 数据重复且分布平均的表字段,因此应该只为经常查询和经常排序的数据列建立索引。注意,如果某个数据列包含许多重复的内容,为它建立索引就没有太大的实际效果。
案例分析:
- 假如一个表有10万行记录,有一个字段A只有T和F两种值,且每个值的分布概率大约为50%,那么对这种表A字段建索引一般不会提高数据库的查询速度。
- 索引的选择性是指索引列中不同值的数目与表中记录数的比。如果一个表中有2000条记录,表索引列有1980个不同的值,那么这个索引的选择性就是1980/2000=0.99。
- 一个索引的选择性越接近于1,这个索引的效率就越高。
索引失效
索引失效(应该避免)
- 建表 SQL
1 | mysql复制代码CREATE TABLE staffs( |
- staffs 表中的测试数据
1 | mysql复制代码mysql> select * from staffs; |
- staffs 表中的复合索引:name、age、pos
1 | mysql复制代码mysql> SHOW INDEX FROM staffs; |
索引失效准则
索引失效判断准则
- 全值匹配我最爱
- 最佳左前缀法则:如果索引了多例,要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。
- 不在索引列上做任何操作(计算、函数、(自动or手动)类型转换),会导致索引失效而转向全表扫描
- 存储引擎不能使用索引中范围条件右边的列
- 尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致)),减少select *
- mysql在使用不等于(!=或者<>)的时候无法使用索引会导致全表扫描
- is null,is not null 也无法使用索引(早期版本不能走索引,后续版本应该优化过,可以走索引)
- like以通配符开头(’%abc…’)mysql索引失效会变成全表扫描操作
- 字符串不加单引号索引失效
- 少用or,用它连接时会索引失效
最佳左匹配法则:带头大哥不能死,中间兄弟不能断
1.只有带头大哥 name 时
- key = index_staffs_nameAgePos 表明索引生效
- ref = const :这个常量就是查询时的 ‘July’ 字符串常量
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name = 'July'; |
2.带头大哥 name 带上小弟 age
- key = index_staffs_nameAgePos 表明索引生效
- ref = const,const:两个常量分别为 ‘July’ 和 23
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name = 'July'AND age = 23; |
3.带头大哥 name 带上小弟 age ,小弟 age 带上小小弟 pos
- key = index_staffs_nameAgePos 表明索引生效
- ref = const,const,const :三个常量分别为 ‘July’、23 和 ‘dev’
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name = 'July'AND age = 23 AND pos = 'dev'; |
4.带头大哥 name 挂了
- key = NULL 说明索引失效
- ref = null 表示 ref 也失效
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE age = 23 AND pos = 'dev'; |
5.带头大哥 name 没挂,小弟 age 跑了,即中间兄弟断了
- key = index_staffs_nameAgePos 说明索引没有失效
- ref = const 表明只使用了一个常量,即第二个常量(pos = ‘dev’)没有生效
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name = 'July'AND pos = 'dev'; |
在索引列上进行计算,会导致索引失效,进而转向全表扫描
1.不对带头大哥 name 进行任何操作:key = index_staffs_nameAgePos 表明索引生效
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name = 'July'; |
2.对带头大哥 name 进行操作:使用 LEFT 函数截取子串
- key = NULL 表明索引生效
- type = ALL 表明进行了全表扫描
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE LEFT(name,4) = 'July'; |
范围之后全失效
1.精确匹配
- type = ref 表示非唯一索引扫描,SQL 语句将返回匹配某个单独值的所有行。
- key_len = 140 表明表示索引中使用的字节数
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name = 'July'AND age = 23 AND pos = 'dev'; |
2.将 age 改为范围匹配
- type = range 表示范围扫描
- key = index_staffs_nameAgePos 表示索引并没有失效
- key_len = 78 ,ref = NULL 均表明范围搜索使其后面的索引均失效
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name = 'July'AND age > 23 AND pos = 'dev'; |
尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致)),减少
select *
1.SELECT *
的写法
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name = 'July'AND age > 23 AND pos = 'dev'; |
2.覆盖索引的写法:Extra = Using where; Using index ,Using index 表示使用索引列进行查询,将大大提高查询的效率
1 | mysql复制代码mysql> EXPLAIN SELECT name, age, pos FROM staffs WHERE name = 'July'AND age = 23 AND pos = 'dev'; |
3.覆盖索引中包含 range 条件:type = ref 并且 Extra = Using where; Using index ,虽然在查询条件中使用了 范围搜索,但是由于我们只需要查找索引列,所以无需进行全表扫描
1 | mysql复制代码mysql> EXPLAIN SELECT name, age, pos FROM staffs WHERE name = 'July'AND age > 23 AND pos = 'dev'; |
mysql在使用不等于(!=或者<>)的时候无法使用索引会导致全表扫描
在使用 != 会 <> 时会导致索引失效:
- key = null 表示索引失效
- rows = 3 表示进行了全表扫描
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name != 'July'; |
is null,is not null 也无法使用索引
is null,is not null 会导致索引失效:key = null 表示索引失效
1 | mysql复制代码ysql> EXPLAIN SELECT * FROM staffs WHERE name is null; |
like % 写最右
staffs 表的索引关系
1 | mysql复制代码mysql> SHOW INDEX from staffs; |
1.like % 写在左边的情况
- type = All ,rows = 3 表示进行了全表扫描
- key = null 表示索引失效
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name like '%July'; |
2.like % 写在右边的情况:key = index_staffs_nameAgePos 表示索引未失效
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM staffs WHERE name like 'July%'; |
解决【like ‘%str%’ 】索引失效的问题:覆盖索引
创建表
1 | mysql复制代码CREATE TABLE `tbl_user`( |
tbl_user 表中的测试数据
1 | mysql复制代码mysql> select * from tbl_user; |
创建索引
1.创建索引的 SQL 指令
1 | mysql复制代码CREATE INDEX idx_user_nameAge ON tbl_user(name, age); |
2.在 tbl_user 表的 name 字段和 age 字段创建联合索引
1 | mysql复制代码mysql> CREATE INDEX idx_user_nameAge ON tbl_user(name, age); |
测试覆盖索引
- 如下 SQL 的索引均不会失效:
+ 只要查询的字段能和覆盖索引扯得上关系,并且没有多余字段,覆盖索引就不会失效
+ 但我就想不通了,id 扯得上啥关系。。。
1 | mysql复制代码EXPLAIN SELECT name, age FROM tbl_user WHERE NAME LIKE '%aa%'; |
1 | mysql复制代码mysql> EXPLAIN SELECT id FROM tbl_user WHERE NAME LIKE '%aa%'; |
- 如下 SQL 的索引均会失效:但凡有多余字段,覆盖索引就会失效
1 | mysql复制代码EXPLAIN SELECT * FROM tbl_user WHERE NAME LIKE '%aa%'; |
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM tbl_user WHERE NAME LIKE '%aa%'; |
字符串不加单引号索引失效
1.正常操作,索引没有失效
1 | mysql复制代码mysql> SHOW INDEX FROM staffs; |
2.如果字符串忘记写 ‘’ ,那么 mysql 会为我们进行隐式的类型转换,但凡进行了类型转换,索引都会失效
1 | mysql复制代码mysql> explain select * from staffs where name=2000; |
少用or,用它连接时会索引失效
- 使用 or 连接,会导致索引失效
1 | mysql复制代码mysql> SHOW INDEX FROM staffs; |
索引失效总结
一般性建议
- 对于单键索引,尽量选择针对当前query过滤性更好的索引
- 在选择组合索引的时候,当前query中过滤性最好的字段在索引字段顺序中,位置越靠左越好。
- 在选择组合索引的时候,尽量选择可以能包含当前query中的where子句中更多字段的索引
- 尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的
索引优化的总结
- like 后面以常量开头,比如 like ‘kk%’ 和 like ‘k%kk%’ ,可以理解为就是常量
like SQL 实测
- = ‘kk’ :key_len = 93 ,请记住此参数的值,后面有用
1 | mysql复制代码----+-------------+--------+------+------------------+------------------+---------+-------------------+------+-----------------------+ |
- like ‘kk%’:
+ key\_len = 93 ,和上面一样,说明 c1 c2 c3 都用到了索引
+ type = range 表明这是一个范围搜索
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2 like 'kk%' AND c3='a3'; |
- like ‘%kk’ 和 like ‘%kk%’ :key_len = 31 ,表示只有 c1 用到了索引
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2 like '%kk' AND c3='a3'; |
- like ‘k%kk%’ :key_len = 93 ,表示 c1 c2 c3 都用到了索引
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2 like 'k%kk%' AND c3='a3'; |
索引优化的总结
全值匹配我最爱, 最左前缀要遵守;
带头大哥不能死, 中间兄弟不能断;
索引列上少计算, 范围之后全失效;
LIKE 百分写最右, 覆盖索引不写 *;
不等空值还有 OR, 索引影响要注意;
VAR 引号不可丢, SQL 优化有诀窍。
索引优化面试题
索引优化面试题
- 建表 SQL
1 | mysql复制代码create table test03( |
- test03 表中的测试数据
1 | mysql复制代码mysql> select * from test03; |
- test03 表中的索引
1 | mysql复制代码mysql> SHOW INDEX FROM test03; |
问题:我们创建了复合索引idx_test03_c1234,根据以下SQL分析下索引使用情况?
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c3='a3' AND c4='a4';
- 即全值匹配
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c3='a3' AND c4='a4'; |
EXPLAIN SELECT * FROM test03 WHERE c4='a4' AND c3='a3' AND c2='a2' AND c1='a1';
- mysql 优化器进行了优化,所以我们的索引都生效了
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c4='a4' AND c3='a3' AND c2='a2' AND c1='a1'; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c3>'a3' AND c4='a4';
- c3 列使用了索引进行排序,并没有进行查找,导致 c4 无法用索引进行查找
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c3>'a3' AND c4='a4'; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c4>'a4' AND c3='a3';
- mysql 优化器进行了优化,所以我们的索引都生效了,在 c4 时进行了范围搜索
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c4>'a4' AND c3='a3'; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c4='a4' ORDER BY c3;
- c3 列将索引用于排序,而不是查找,c4 列没有用到索引
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c4='a4' ORDER BY c3; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' ORDER BY c3;
- 那不就和上面一样的嘛
~,c4 列都没有用到索引
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' ORDER BY c3; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' ORDER BY c4;
- 妈耶,因为索引建立的顺序和使用的顺序不一致,导致 mysql 动用了文件排序
- 看到 Using filesort 就要知道:此句 SQL 必须优化
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' ORDER BY c4; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c5='a5' ORDER BY c2, c3;
- 只用 c1 一个字段索引,但是c2、c3用于排序,无filesort
- 难道因为排序的时候,c2 紧跟在 c1 之后,所以就不用 filesort 吗?
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c5='a5' ORDER BY c2, c3; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c5='a5' ORDER BY c3, c2;
- 出现了filesort,我们建的索引是1234,它没有按照顺序来,32颠倒了
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c5='a5' ORDER BY c3, c2; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' ORDER BY c2, c3;
- 用c1、c2两个字段索引,但是c2、c3用于排序,无filesort
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' ORDER BY c2, c3; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c5='a5' ORDER BY c2, c3;
- 和 c5 这个坑爹货没啥关系
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c5='a5' ORDER BY c2, c3; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c5='a5' ORDER BY c3, c2;
- 注意查询条件 c2=‘a2’ ,我都把 c2 查出来了(c2 为常量),我还给它排序作甚,所以没有产生 filesort
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c2='a2' AND c5='a5' ORDER BY c3, c2; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c4='a4' GROUP BY c2, c3;
- 顺序为 1 2 3 ,没有产生文件排序
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c4='a4' GROUP BY c2, c3; |
EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c4='a4' GROUP BY c3, c2;
- group by 表面上叫分组,分组之前必排序,group by 和 order by 在索引上的问题基本是一样的
- Using temporary; Using filesort 两个都有,我只能说是灭绝师太
1 | mysql复制代码mysql> EXPLAIN SELECT * FROM test03 WHERE c1='a1' AND c4='a4' GROUP BY c3, c2; |
- 结论:
+ group by 基本上都需要进行排序,但凡使用不当,会有临时表产生
+ 定值为常量、范围之后失效,最终看排序的顺序
本文转载自: 掘金