MySQL优化面试准备

想了很久要不要发一篇关于MySql优化的文章最后还是决定把它写出来。以输出倒逼自己复习与输入。以下内容大都参考了《高性能MySQL》一书也好把一些的章节做一个总结。全文的聊到的三个主要能容是：

MySql的特点与存储引擎

MySql高性能索引

MaySql的数据类型优化与查询性能优化

MySql的特点与存储引擎

MySql的总体架构图

用户执行Mysql的流程图：

上层的一些服务并不是Mysql特有的，比如说Mysql的服务器会启动连接池然后对客户端做连接处理授权认证安全等工作。

中间的架构包括查询解析、分析、优化和缓存等跨存储引擎的过程。

底层是存储引擎，负责Mysql数据的存储和提取，但是一般的存储引擎是不会去解析SQL语句的（但是InnoDB可以去解析外键的定义），不同的存储引擎之间是不会通信的而只是单纯的处理上层服务器的请求。

 

数据库中的锁

按照互斥性来说

共享锁（之间不互斥），排他锁（与其他任意锁都互斥）。在一般情况下读锁是共享锁，写锁是排他锁。需要注意的是，写锁的优先级比较高一个写锁的请求可能被插入到读锁队列的前面反之不然。

按照粒度来说

一般有表锁（粗粒度效率低）与行锁（细粒度并发效率高）。所谓的锁的策略就是在锁的开销与数据的安全性之间寻找一个平衡。

死锁

就是多个事务在同一资源上相互占用，并锁定对方占用的资源从而导致的恶性循环的现象。好在Mysql会自动检测和处理死锁。InnoDB的处理策略是将持有最少行级排他锁的事物回滚。

事务（略）

这里只强调一点就是，没有100%的持久化，否则备份是不会增加持久性的。

另一种高并发策略——MVCC

Mysql大多数的存储引擎并不是简单是实现了行级锁，他们同时实现了MVCC（多版本并发控制）。MVCC可以认为是行级锁的一个变种，但是它在很多的情况下都避免了加锁（只有在写入操作的时候才加锁）。MVCC是通过保存数据在某一个时间点的快照来实现的，也就是不管什么时候每个事物看到的数据都是一致的。也就是可能存在不同的事务在同一时刻看到的数据是不同的。别着急我们慢慢来。

MVCC的原理就是在数据的每一行后面增加两个列，一列保存的是创建时间另一列保存的是删除时间（准确的说是系统的版本号）。下面我们以REPEATABLE READ的隔离级别举个例子。

 

SELECT

首先是查询，当一个事务开启是能够查到的数据得满足两个条件

• 创建时间在当前事务开启之前（包含当前事务）
• 删除时间在当前事务之后

只有同时满足这两个条件的行才能够被当前的事务所查到。

INSERT

当当前的事务新增一条数据的时候，会将当前的版本号分配给当前新增的每一行。

 

DELETE

会将当前的版本号分配给删除的每一行作为删除时间。

UPDATE

会新插入一条数据版本号为当前的事务版本号，旧的那一条数据会设置当前事物的版本号为删除时间。

 

总结：增加了这样的两个版本号，会使得效率大大提高但是会花掉空间的成本。

 

InnoDB与MyISAM存储引擎的区别

比较项目	InnoDB	MyISAM
数据存储	存在表空间（是由InnoDB管理的黑盒子由一系列数据文件组成）	存储在数据文件与索引文件中
事务	支持事务	不支持事务
行级锁	支持行级锁	不支持行级锁（但是支持表级索）
全文检索	不支持全文检索	支持全文检索
外键	支持外键	不支持外键

 

Momory引擎

所有的数据都保留在内存中，不需要进行磁盘的IO所以读取的速度很快。但是一旦关机的话表的结构会保留但是数据就会丢失。

Memory表支持Hash索引，因此查找速度很快。即便如此它还是不能代替基于磁盘的引擎因为它只是支持表锁所以并发写入的效率不高。同时它不支持TEXT与BLOB数据类型，而且没有varchar类型（即使写了varchar也会自动转换成char类型）所以会造成内存的浪费。

 

总结：默认使用InnoDB存储引擎。例如：即使是需要全文索引我们也可以通过InnoDB与Sphinx的组合，而不是直接使用MyISAM。

 

创建高性能的索引

索引的概念就不多说了，这种数据结构可以大幅度的减少我们查找数据的时间。从架构上来说它是在存储引擎层面实现的。

B-Tree与B+Tree索引

先上图：

（图片来自csdn gitchat）

从图中我们可以看到数据的特点。所有真实的数据都是排好序的在B-Tree的**非叶节点和叶子节点上**，这些节点到根的距离是一样的。当我们要查找一个具体的数据的时候，首先会从根节点开始找每一次都会根据大小选择一个分支，这样的话大大减少了查找的次数。从此再也不需要全表的扫描了。同时B-Tree的数据是按照顺序来存放的对顺序值的查找（对索引列进行OrderBy操作）也是非常快的。这样的话避免了很多随机的IO。

这里需要注意的是如果存在多个索引数据库的排序规则。按照create 表的时候的索引出现的先后顺序来排序的。如果前一个指标一样那么则使用后一个指标来排序。同时如果有多列索引的话那么我们只能够从最左列开始查找。不能跳过索引的列，所以对于列的先后顺序也是我们优化的一个指标。

最后，B+Tree相对于B-Tree （1）所有的数据都在结点上，非叶节点之所作为索引。（2）叶子结点之间有指针关联（3）B+树才是真正的"B加树"--B树索引+数据

 

哈希索引

哈希索引的底层是Hash表，每查一个值之前首先计算它的hashcode然后找到对应数据的指针，最后根据指针去找到真实数据。它有以下几点注意事项：

• 只能使用精确查询，这个与hash表的特点有关。
• 它不是按照索引值的顺序来存储的所以不能用于排序。
• 只能有等值查询不能查询>  < 等关系运算。
• Hash冲突时会遍历对应Hash码的对应的链表的所有节点，而且维护成本高每删除一条记录时就会修改对应的Hash表。

自适应Hash索引

在innodb中如果有些索引使用的非常频繁的时候，就可以考虑使用自适应Hash索引。它对查询的性能的提升是非常明显的。

它的设计原理非常简单，就是让一个字段的Hash值作为索引，然后再使用B+Tree来进行查询。从这里我们可以看出这与真正的Hash索引是不同的，真正执行查询的是B+Tree，我们只是在查询之前计算了一次Hash值。这样我们可以做出以下的优化，案例如下：

select id from url_table where url="baidu.com";

select id from url_table where url="baidu.com" and url_crc = crc32("baidu.com");

其中crc32就是我们所指定的Hash函数。如果以它为索引，那么Mysql的优化器就会选择性能高的url_crc来实现查找。即使出现了hash冲突（也就是同一个Hash值会对应不同的url）我们也早已过滤掉了大部分的无用信息而不再像从前一样进行逐个比较了。当然自适应Hash索引也有自己的优点就是需要维护Hash索引，而且要处理Hash冲突尤其是在数据量较大的情况下。这里给出一个处理Hash冲突的建议就是使用多个where条件来保证查询的准确性。

小节：索引的优点

1. 索引大大减少了服务器需要扫描的数据量。
2. 索引可以避免服务器排序和建立临时表。
3. 索引可以将随机的IO变成顺序的IO。

 

高性能索引的策略

独立的列

独立的列是指，索引列不能成为表达式或者参数的一部分否则就会失效。比如说下面的索引列就没有发挥作用。

比如actor_id列为索引列那么索引要放在where或order by里面
Select actor_id from mytable where actor_id + 1 = 5;

前缀索引和索引的选择性

在数据量大索引的字段过长的时候，索引本身也会占用较大的空间。这样会使得索引变得大而且慢，所以我们有时候使用索引的前缀来代替索引以此来减短索引列的长度减少索引所占的空间。

这里不得不提出一个概念就是索引的选择性，它是指不重复的索引值与记录总数的比值。索引的选择性越高则查询性能越高，因为在查询时会过滤掉更多的行。唯一索引的选择性是1，而大多数的索引往往是一对多的。与此同时在数据库上有这样的一个事实，使用的索引前缀越短则索引的选择性越低，使用的索引越长则索引的选择性越高。这就出现了一个高选择性与短前缀之间的一种平衡。我们的策略是尽可能的选择一个临界值的长度一旦超过这个长度索引的选择性会提升的很慢。那么这个时候我们的前缀索引是性价比最高的。

选择合适的索引列顺序

当有多列索引时，索引列的顺序极大的影响着我们的查询效率。通常情况下（不考虑排序和分组的情况下）我们把高选择性的索引列放在最前面，以保证在查询刚开始的时候就可以过滤大部分的数据。实务上我们需要根据经验来调整索引的顺序，比如说把IO的优化放在第一位，甚至是修改程序代码来达到查询的优化。

举个栗子：

查找一个名字叫“主流7”，而且在15软件G2班的同学的信息。

已知名字叫主流7的人有10000条，而15软件G2班只有30人。这个时候我们优先查出15软件G2班的人然后再去找名字叫主流7的人的效率要远远高于，找出所有名字叫主流7的人然后再看那个是属于15软件G2班的人的效率。

聚簇索引

聚簇索引不是一种单独的数据存储类型而是一种数据的存储方式，。所谓聚簇就是数据和相邻的键值紧凑的存放在一起（也就是数据怎么存放索引就怎么建立）所以一个表只能够有一个聚簇索引，因为它的数据只能以一种方式来存储。（聚簇索引的定义还待考究）。

 

聚簇索引与非聚簇索引（二级索引）

聚簇索引与非聚簇索引的具体实现与底层的存储引擎相关。下面分别以MySQL中的两大主流引擎来展开讨论。

InnoDB

InnoDB的聚簇索引就是表本身，它由表的数据与B+Tree索引组成。

其中内部节点中包括索引列和指向下一节点的指针，而叶子节点包括表所有列上的数据，比如主键列，MVCC列，回滚列其它列等等。所以我们在查询数据时直接就能够查找到我们想要的数据。

InnoDB的二级索引（非聚簇索引）

内部结点中包含索引列与指向下个节点的指针，而叶子节点则包括索引列和主键值。这也就造成了如果我们想要通过二级索引去查询一条数据的啥时候需要两轮的查询，第一轮是通过B+Tree查找到主键值，第二轮就是拿着主键值再经过一次B+Tree的查找找到真实的值。

MyISAM

MyISAM的索引聚簇索引和非聚簇索引原理相同，就是内部结点都包含有索引列和指向下一个节点的指针，在叶子节点中包含的是行号，指向实际的物理地址。

 

避免随机的聚簇索引

当表中没有什么数据需要聚集时，我们一般可以使用一个代理主键（与业务无关的键）去作为聚簇索引比如说一列自增的键。自增的键有一个好处就是在增加一条记录的时候会按照顺序插在最后面这样的话会非常节省资源因为它既避免了页分裂同时也避免了由页分裂而产生的内存碎片化。

另一方面，随机的聚簇索引（特别是对于一些IO密集的应用）使用随机的聚簇索引是很糟糕的，它使得聚簇索引的插入变得完全随机，使得数据完全没有聚集特性。下面具体说说随机的聚簇索引的缺点：

• 将要写入的目标页有可能已经不在内存中（或者是缓存中了），所以在写入时首先需要将目标页从硬盘读到内存中。这将导致大量的随机IO。
• 因为写入时乱序的，所以InnoDB不得不频繁的做页分裂操作，这将会大量的移动数据。
• 由于页分裂，所以会导致页变得稀疏并且不规则的填充，最终数据会有碎片。

综上我们要避免随机的聚簇索引。顺便自增的索引在高并发的时候也会产生线程安全问题，所以我们可以使用innodb_autoinc_lock_mode参数配置来保证自增的原子性。

小节

简单说一下InnoDB的聚簇索引的特点：

1. 通过一个指标把与这个指标相关联的数据聚集起来，当查询与这个指标相关的数据时能够避免多次IO带来的效率底下。但是，当数据都在内存中进行运算时这时也就不会有

IO带来的效率问题了。

1. 查询速度快，不像二级索引一样需要两轮查找。
2. 索引的维护成本高，更新聚簇索引插入新的行可能会造成如果按照索引的顺序插入还好但是如果一旦在中间插入新的行就会导致页分裂的问题这样既使得更新的效率低下，又会造成内存的浪费。

覆盖索引

如果一个索引中包含我们想要查的那一列的值，我们就说这个索引就是覆盖索引。当我们需要查询被覆盖的列的值的时候可以直接查询覆盖索引中的值而无需回到表中查询数据。这样我们就可以说这次查询的表中的数据被索引中的数据给覆盖了。下面介绍它的一些优点：

• 可以配合InnoDB的二级索引来实现单次查询，如果二级索引能够覆盖查询就能够办到。
• 因为索引是按照顺序的（或者是局部有序）那么对于当前列值的IO密集型范围查询会大大减少随机IO。
• 索引的条目通常远小于数据行的大小，如果能直接从索引中获取数据那么会极大地减少数据的访问。减少了服务器的负载压力。

不是所有的引擎都支持覆盖索引，MySQL只支持基于B-Tree的覆盖索引。有的查询是是不能够使用覆盖索引的，比如说非前缀的like模糊查询。还有的查询他们要查询表中的很多列没有一个所以是可以覆盖很多列的所以只能够先利用覆盖索引过滤掉大多数的数据行，然后再在这个基础上进行查询，我们把这种查询方式叫做延迟关联。

 

数据类型优化与查询优化的一些经验法则

数据类型优化

MySQL支持的数据类型是很多的，选择好合适的数据类型对于节省内存和提升性能意义重大。下面介绍几点经验法则：

1. 如果能够正常存储数据那么一般使用更小的数据类型。
2. 尽量避免null值，null值可以是任何数据类型的默认值，但是null使得索引索引统计和值的比较都变得复杂。
3. TIMESTAMP与DATATIME的选择，TIMESTAMP的时间范围较DATATIME小的多，但是

TIMESTAMP占用的内存是DATATIME的一半并且能够随着时区不断地变化。

1. 整数类型有可选的unsigned属性，如果我们的数值无需负数的话那么推荐使用这种类型，举例来说TINYINT UNSIGNED与TINYINT的存储范围都是256但是前者是0~255，后者是-128~127。
2. DECIMAL类型是一种存储方式，它可以用于精确计算。在计算过程中它会转化成double类型，但是DECIMAL的精确计算代价很高。为了减少这种高消耗我们可以在保留精度的条件下使用BIGINT来存储数据。举例来说，比如要保留6位小数，那么我们在存储数据的时候就可以给每一个数乘以100万，然后在取数据的时候在给每一个数除以100万。以减少代价。
3. Varchar与char。它们的存储方式与存储引擎相关，下面以InnoDB或MyISAM为例。

Varchar长度可变一般来说是节省空间的，但是如果使用ROW_FORMAT=FIXED参数创建表的话那么varchar也是固定的长度。Varchar有一个特点就是需要在存储空间末尾开辟一到两个字节记录字符串的长度。当字符串长度的方差大的时候（比如说使用了UTF-8这样的字符集）那么推荐使用varchar。

Char是定长的数据类型，非常适合存储定长的数据比如说MD5码。对于非常短的列也有非常高的效率，比如说表示一个只有true/false的值char(1)的效率要高于varchar(1)因为varchar(1)后面会附加一个记录长度的额外字节。

1. 当存储IP地址时使用无符号整数，因为IP地址本来就是32位的无符号整数。使用

INET_ATON()与INET_NTOA()完成他们之间的转换。

查询优化

搞清楚查询的生命周期对于优化查询是十分必要的，如果把查询看作是一个任务那么它就是由很多的子任务所构成。查询的生命周期大致可以分为这样的几个阶段：从客户端到服务器，然后在服务器上解析，生成执行计划、执行最后返回结果给客户端。这里我再次贴上这张图

其中执行阶段可以认为是最重要的阶段这一阶段包括大量的检索数据到存储引擎的调用以及调用后的数据处理，包括排序，分组等。除此之外查询还要在不同的地方花费时间，包括网络，CPU计算，生成统计信息和执行计划，锁等待等等。

优化数据访问

减少请求无用的数据，比如说我们查询了100条数据但是最后只在得到的结果中取了其中的10条（在应用程序中完成的）。这样不仅仅是耗费了大量的计算机资源也耗费了大量的网络资源。所以在这种情况下我们尽早使用limit语句来过滤或者是使用索引来过滤。

重构查询方式

一般情况下我们倾向于使用尽可能少的SQL语句去完成查询操作，这样能够减少发送查询的次数。但是有时候我们需要将大的查询拆分成一些小的查询。比如说在删除大量的数据时数据库（假设数据库支持锁）会将大量的数据锁住这样的话其它的语句就会在队列中等待。这时候将删除的任务分为几波就可以更加高效。

有时候我们也需要将查询的连接放在应用中，将一个连接查询拆分成几个小的查询。这样带来的的好处就是避免了几张表连接时占用的大量内存，而且更加有利于利用缓存（如果关联的表中某个表发生了改变将无法使用缓存，但是当拆开之后某个表发生了细微的变换之后还可以使用缓存）。最后拆开之后还可以减少锁的竞争。

优化特定类型的查询

这里仅仅介绍几个经验的法则：

• 当统计行数的时候尽量使用count(*)，当我们以某一列为统计指标的时候，如果碰到null的时候就会不把这一行统计在内。而在MySQL的底层也会将count(col)优化成count(*)。
• 要尽可能的保证GROUP BY和ORDERBY语句中只包含一个列，这样MySQL才有可能使用索引来优化查询。
• 要时时注意子查询，子查询构成的虚表是没有任何索引的。
• 优化LIMIT分页，在一般情况下我们会使用LIMIT加上偏移量来搞定，这时如果有合适的索引的话效率一般不会错，但是如果只是一味的使用LIMIT语句的话，比如有1000,20这样的语句的话前面的需要查询1020条记录然后抛弃前面的1000条数据，这个代价是非常高的。一般的做法是尽可能的使用覆盖索引（里面可以包含我们想要的值）做延迟关联这样的效率就会很高。举个例子：以下代码使用方案2
```cpp select film_id,description, from sakila.film order by title limit 50,5;

Select film.film_id,film.description

from sakila.film

inner join(

Select film_id from sakila.film order by title limit 50,5

) as lim using(film_id);

至此我的有关于数据库的优化的知识点输出完毕。同时也希望能够帮助到你。最后，欢迎批评。</p>                                    </div>