首先我们回顾一下上篇内容，主要复习了索引，事务，锁，以及SQL优化的工具。本篇文章接着写后面的内容。

性能优化

1. 索引优化，SQL中索引的相关优化主要有以下几个方面：

• 最好是全匹配。
• 如果是联合索引的话，遵循最左前缀匹配。比如联合索引(a,b,c)，这时我们的查询条件可以是(a)(a,b)(a,b,c)。
• 如果是联合索引，范围查询的右边的列，是无法走索引的。
• 查询条件中的列如果进行了一些操作，如计算，函数，隐式转换等，无法使用索引。
• 字符串如果不用引号，无法使用索引。
• !=,<>,not in无法使用索引。<,>,<=,>=,in,between可以使用索引。
• or不能使用索引。
• like 左前缀固定可以使用索引（"xxx%"）,后缀固定无法使用索引（"%xxx"）
• null,not null 无法使用索引。
• 尽量使用覆盖索引。

2. 查询优化，SQL中除了索引优化，还有很多查询优化。

• 小表驱动大表：对于IN子查询，尽量子查询中的表数据量要远小于外部的主表。如果子查询中的表数据量远大于主表，那么使用exists由于in。
• order by：尽量使用index方式排序，不要用FileSort排序，遵循最左前缀。如果只能用FileSort方式排序，可以通过调整sort_buffer_size和max_length_for_sort_data。
• group by：本质是排序后分组，所以优化跟order by一样。其次，where条件先执行，所以能在where条件中限制的就不要写在having里了。

3. 数据类型优化。

• 应该尽量使用可以正确存储数据的最小数据类型。
• 尽量避免NULL：通常情况下最好指定列为NOT NULL。

分区

InnDB将数据存储在.idb和.frm中，当数据量极大时，我们的数据库性能会急剧下降，这时，我们可以利用分区，将数据分成多个数据文件来存储，提高每个文件的查询效率。

分区类型：

• RANGE分区：基于属于一个给定连续区间的列值，把多行分配给分区。常见有时间范围分区。
• LIST分区：每个分区的定义和选择是基于某列的值从属于一个值列表集中的一个值。
• HASH分区：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算。
• KEY分区：类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值。

分表

分为垂直拆分和水平拆分。

垂直拆分：将一个大表的列拆分多个表，每个表存储不同的列，这几个表的关系是一对一。通常，我们会拆分成一个基础表，一个扩展表等等。

水平拆分：将一个大表拆分成同一schema的多个表。数据根据某种规则将某一列进行拆分。

水平拆分方法：

• 使用MD5哈希，做法是对UID进行md5加密，然后取前几位（我们这里取前两位），然后就可以将不同的UID哈希到不同的用户表（user_xx）中了。
• 还可根据时间放入不同的表，比如：article_201601，article_201602。
• 按热度拆分，高点击率的词条生成各自的一张表，低热度的词条都放在一张大表里，待低热度的词条达到一定的贴数后，再把低热度的表单独拆分成一张表。
• 根据ID的值放入对应的表，第一个表user_0000，第二个100万的用户数据放在第二 个表user_0001中，随用户增加，直接添加用户表就行了。

分库

一个库里表太多了，导致了海量数据，系统性能下降，把原本存储于一个库的表拆分存储到多个库上， 通常是将表按照功能模块、关系密切程度划分出来，部署到不同库上。

主从复制

主从复制的原理，主要是通过binlog来实现的。

1. master改变数据时，会将数据改变的事件写入到binlog中。
2. slave从binlog中将事件数据copy到自己的中继日志中。
3. slave通过中继日志重做事件，把数据更新到自己节点数据中。

binlog：STATEMENT模式，row模式，mix模式。

MYSQL的查询语句的执行过程：

（这个竟然也有考的，记录一下）

客户端请求 ---> 连接器（验证用户身份，给予权限） ---> 查询缓存（存在缓存则直接返回，不存在则执行后续操作） ---> 分析器（对SQL进行词法分析和语法分析操作） ---> 优化器（主要对执行的sql优化选择最优的执行方案方法） ---> 执行器（执行时会先看用户是否有执行权限，有才去使用这个引擎提供的接口） ---> 去引擎层获取数据返回（如果开启查询缓存则会缓存查询结果）