关于MySQL调优

前言

调优有四个大方向，对于程序员来说，关注SQL调优就够了

就算是SQL调优，解锁姿势也很多，跟别人交(chui)流(shui)经验的时候，你记得过来吗，今天分享一种方便记忆的方式，毕竟

正文

调优，翻译过来不就是BETTER吗

1. B+（最左前缀索引、覆盖索引）
2. Explain（执行计划）
3. Tui（推，索引下推）
4. Type（类型检查）
5. Engine（存储引擎）
6. Return（回表查询）

好了，记住这个单词，我们一个个来

本文的定位在于跟他人交流的时候，怎么尽可能多的描述出来~（当然前提是你已经掌握了这些知识）

所以默认大家已经熟悉了MySQL调优的一些知识点，下面只是为了帮忙大家简单复习一下，对于部分知识点，文末也给出了一些博客链接，写得都非常好了，就没必要搬运过来了

1. B+

索引的底层数据结构是B+树（又学了个知识点），关于索引，之后会单独出一篇博客

尽可能的使用索引，但也不能滥用

1. 不在大字段上建索引
2. 不在频繁修改的列上建索引
3. 不在重复值多的列上建索引

联合索引和最左前缀原则

索引本质上就是一种有序的数据结构，联合索引的原理，跟字符串排序类似

字符串底层是byte[]，”221“<”235”<“311”，本质是比较[2, 2, 2]，[2, 3, 5]和[3, 1, 1]。大致流程如下：

1. 先是比较数组的第一个元素，2=2<3
2. 相同时，再接着比较下一个元素，比如上面的2=2时，会比较数组的第二个元素，分别是2和3
3. 可以看到对于数组第一个元素2 2 3是有序的，第二个元素2 3 1和第三个元素2 5 1都是无序的，但也不是完全无序，是在前面元素相等的情况下部分有序

理解了上面之后，理解起联合索引失效没那么难了

1. 没遵循最佳左前缀法则
2. 范围查询的右边会失效，因为前一个字段走了索引后，数据对于后一个字段来说是无序的，索引自然就失效了
3. like查询用不到索引，字符串like时，比如%是在字符串左边，由于前面的索引没生效，所以后面的是无序的情况，也就走不了索引，变成全表扫描了

优化的时候尽量往联合索引方面优化，即尽可能使用索引，不让索引失效

尽量使用索引覆盖

select * 能不使用就不使用，尽量只查询需要的字段

2. Explain（执行计划）

加完索引后，就要看执行计划，是否走了索引，优化器做了哪些优化

关于Explain，也有很多东西可以讲，暂时没想到一个好的梳理方式，等以后想到了再补充吧

3. T（Tui，索引下推）

索引下推在非主键索引上的优化，可以有效减少回表的次数，大大提升了查询的效率

Explain的Extra列出现Using index condition，则表示使用了索引下推

4. Type（类型检查）

数据类型及schema优化

1. 类型越小越好，能用TinyInt就尽量不用Int
2. 尽量不使用Null，采用默认值代替
3. 不使用TEXT

5. Engine（存储引擎）

常选的myisam和innodb

1. innodb支持表锁、行锁、事务、聚簇索引，适合insert/update/delete
2. myisam支持表锁、非聚簇索引，适合大量select

当然关于myisam和innodb的区别有很多很多，有本专门介绍innodb的书籍，有兴趣的小伙伴也可以去看一下

6. Return（回表查询）

能索引覆盖就索引覆盖，尽量减少回表查询的次数

参考文章

【数据库调优】屡试不爽的面试连环combo
索引失效原理，终于有人讲明白了
回表与覆盖索引，索引下推

结语

篇幅没写那么长，感觉写太长容易劝退，大家时间都很宝贵，没少吃快餐文化，我自己也是深度受害者。就先这样吧，再多的，等以后想起来了再补充，毕竟学习本来就需要经常回顾