MySQL索引优化详解

MySQL存储引擎简介

1. 查看命令

   a. 查看所使用的MySQL如今已提供什么存储引擎：

   mysql> show engines;

   b. 查看所使用的MySQL当前默认的存储引擎：

   mysql> show variables like '%storage_engine%';

2. MyISAM和InnoDB两种存储引擎的区别

   对比项	MyISAM	InnoDB
   主外键	不支持	支持
   事务	不支持	支持
   行表锁	表锁，即便操纵一条记录也会锁住整个表，不适合高并发的操做	行锁，操做时只锁某一行，不对其余行有影响，适合高并发的操做
   缓存	只缓存索引，不缓存真实数据	不只缓存索引还要缓存真实数据，对内存要求较高，并且内存大小对性能有决定性的影响
   表空间	小	大
   关注点	性能	事务
   默认安装	Y	Y

   • 事务属性（既然提到，就顺带复习一下）
     事务是由一组SQL语句组成的逻辑处理单元，事务具备如下4个属性，一般简称为事务的ACID属性。
     • 原子性（Atomicity）：事务是一个原子操做单元，其对数据的修改，要么全都执行，要么全都不执行
     • 一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态，这意味着全部相关的数据规则都必须应用于事务的修改，以保持数据的完整性。事务结束时，全部的内部数据结构（如B树索引或双向链表）也都必须是正确的
     • 隔离性（Isolation）：数据库系统提供必定的隔离机制，保证事务在不受外部并发操做影响的“独立”环境执行，这意味着事务处理过程当中的中间状态对外部是不可见的，反之亦然
     • 持久性（Durable）：事务完成以后，它对于数据的修改是永久性的，即便出现系统故障也可以保持
   • 并发事务处理带来的问题
     • 更新丢失（Lost Update）
       当两个或多个事务选择同一行，而后基于选定的值更新该行时，因为每一个事务都不知道其余事务的存在，就会发生丢失更新的问题——最后的更新覆盖了由其余事务所作的更新。
       例如，两个程序员修改同一java文件。每一个程序员独立地更改其副本，而后保存更改后的副本，这样就覆盖了原始文档。最后保存其更改副本的编辑人员覆盖前一个程序员所作的更改。
       若是在一个程序员完成并提交事务以前，另外一个程序员不能访问同一文件，则可避免此问题。
     • 脏读（Dirty Reads）
       一个事务正在对一条记录作修改，在这个事务完成并提交前，这条记录的数据就处于不一致状态；这时，另外一个事务也来读取同一条记录，若是不加控制，第二个事务读取了这些“脏”数据，并据此作进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象地叫作“脏读”。
       一句话：事务A读取到了事务B已修改但还没有提交的数据，还在这个数据基础上作了操做，此时，若是B事务回滚，A读取的数据无效，不符合一致性要求。
     • 不可重复读（Non-Repeatable Reads）
       一个事务在读取某些数据后的某个时间，再次读取之前读过的数据，却发现其读出的数据已经发生了改变，或某些记录已经被删除了！这种现象就叫作“不可重复读”。
       一句话：事务A读取到了事务B已经提交的修改数据，不符合隔离性。
     • 幻读（Phantom Reads）
       一个事务按相同的查询条件从新读取之前检索过的数据，却发现其余事务插入了知足其查询条件的新数据，这种现象就称为“幻读”。
       一句话：事务A读取到了事务B已提交的新增数据，不符合隔离性。
       多说一句：幻读和脏读有点相似：脏读是事务B里面修改了数据，幻读是事务B里面新增了数据。

   • 事务隔离级别
     “脏读”、“不可重复读”和“幻读”，其实都是数据库读一致性问题，必须由数据库提供必定的事务隔离机制来解决。

     读数据一致性及容许的并发反作用	读数据一致性	脏读	不可重复读	幻读
     Read uncommitted	最低级别，只能保证不读取物理上损坏的数据	是	是	是
     Read committed	语句级	否	是	是
     Repeatable read	事务级	否	否	是
     Serializable	最高级别，事务级	否	否	否

     数据库的事务隔离越严格，并发反作用越小，但付出的代价也就越大，由于事务隔离实质上就是使事务在必定程度上，“串行化”进行，这显然与“并发”是矛盾的。同时，不一样的应用对读一致性和事务隔离程度的要求也是不一样的，好比许多应用对“不可重复读”和“幻读”并不敏感，可能更关心数据并发访问的能力。
     查看MySQL的事务隔离级别：show variables like 'tx_isolation';

性能降低的缘由

包括但不限于下列状况：

1. 查询语句写的烂
2. 索引失效
3. 关联查询太多join（设计缺陷或不得已的需求）
4. 服务器调优即各个参数设置（缓冲、线程数等）不合理

索引简介

MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。能够获得索引的本质：索引是数据结构。
索引的目的在于提升查询效率，能够类比字典，好比：若是要查“MySQL”这个单词，咱们确定须要定为到m字母，而后从上往下找到y字母，再找到剩下的s、q、l。若是没有索引，那么你可能须要a--z，若是我想找到Java开头的单词呢？或者Oracle开头的单词呢？是否是以为若是没有索引，这个事情根本没法完成？
你能够简单理解为“排好序的快速查找的数据结构”。

• 详解
  在数据以外，数据库系统还维护着知足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就能够在这些数据结构上实现高级查找算法。这种数据结构，就是索引。下图就是一种可能的索引方式示例：
  

  为了加快Col2的查找，能够维护一个右边所示的二叉查找树，每一个节点分别包含索引键值和一个指向对应数据的记录物理地址的指针，这样就能够运用二叉查找在必定的复杂度内获取到相应数据，从而快速的检索出符合条件的记录。

• 结论
  数据自己以外，数据库还维护着一个知足特定查找算法的数据结构，这些数据结构以某种方式指向数据，这样就能够在这些数据结构的基础上实现高级算法，这种数据结构就是索引。
  通常来讲，索引自己也很大，不可能所有存储在内存中，所以索引每每以索引文件的形式存储在磁盘上。
  咱们日常所说的索引，若是没有特别指明，都是指B树（多路搜索树，并不必定是二叉树）结构组织的索引。其中汇集索引，次要索引，覆盖索引，复合索引，前缀索引，惟一索引默认都是使用B+数索引，统称索引。固然，除了B+树这种类型的索引以外，还有哈希索引（hash index）等。

• 优点
  相似大学图书馆创建书目索引，提升数据检索的效率，下降数据库的IO成本。经过索引列对数据进行排序，下降数据排序的成本，下降了CPU的消耗。

• 劣势
  实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，因此索引列也是要占用空间的。
  虽然索引大大提升了查询速度，同时却会下降更新表的速度，如对表进行INSERT、UPDATE和DELETE。由于更新表时，MySQL不只要保存数据，还要保存一下索引文件每次更新添加了索引列的字段。
  索引只是提升效率的一个因素，若是你的MySQL有大数据量的表，就须要花时间创建最优秀的索引，或优化查询。

• MySQL索引分类
  创建复合索引优于创建单值索引。通常而言，一张表最多建5个索引

1. 单值索引：即一个索引只包含单个列，一个表能够有多个单列索引。
2. 惟一索引：索引列的值必须惟一，但容许有空值。
3. 复合索引：即一个索引包含多个列。

• 基本语法

  • 建立
    CREATE [UNIQUE] INDEX indexName ON mytable(columnname(length));
ALTER mytable ADD [UNIQUE] INDEX [indexName] ON (columnname(length));
  • 删除
    DROP INDEX [indexName] ON mytable;
  • 查看
    SHOW INDEX FROM table_name;
  • 使用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索引结构

1. Btree
   尽可能增长检索广度，不增长深度。检索原理：

   初始化介绍：一棵B+树，浅蓝色的块，咱们称之为一个磁盘块，能够看到每一个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示）。
   如磁盘块1包含数据项17和35，包含指针P一、P二、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。
   真实的数据存在于叶子节点，即三、五、九、十、1三、1五、2八、2九、3六、60、7五、7九、90、99。
   非叶子节点不存储真实的数据，只存储指引搜索方向的数据项，如1七、35并不真实存在于数据表中。
   查找过程：若是要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找肯定29在17和35之间，锁定磁盘块1的P2指针，内存时间由于很是短（相比磁盘的IO）能够忽略不计，经过磁盘块1的P2指针的磁盘地址把磁盘3由磁盘加载到内存，发生第二次IO，29在26到30之间，锁定磁盘块3的P2指针，经过指针加载磁盘块8到内存，发生第三次IO，同时内存中作二分查找找到29，结束查询，总计三次IO。
   真实的状况是，3层的B+树能够表示上百万的数据，若是上百万的数据查找只须要三次IO，性能提升将是巨大的，若是没有索引，每一个数据项都要发生一次IO，那么总共须要百万次的IO，显然成本很是很是高。
2. Hash
3. full-text

4. R-Tree

哪些状况须要建立索引

1. 主键自动创建惟一索引
2. 频繁做为查询条件的字段应该建立索引
3. 查询中与其余表关联的字段，外键关系创建索引
4. 频繁更新的字段不适合建立索引：由于每次更新不只仅是更新了记录还会更新索引
5. where条件里用不到的字段不建立索引
6. 单键/组合索引的选择问题，which？（在高并发下倾向建立组合索引）
7. 查询中排序的字段，排序字段若经过索引去访问，将大大提升排序速度
8. 查询中统计或者分组字段

哪些状况不须要建立索引

1. 表记录太少（建议：一百万条之内的数据不建议创建索引，由于足够hold得住）
2. 常常增删改的表
   why：虽然提升了查询速度，同时却会下降更新表的速度，如对表进行INSERT、UPDATE和DELETE。由于更新表时，MySQL不只要保存数据，还要保存一下索引文件。
3. 数据重复且分布平均的表字段，所以应该只为最常常查询和最常常排序的数据列创建索引。
   注意：若是某个数据列包含许多重复的内容，为它创建索引就没有太大的实际效果。
   假如一张表有10万行记录，有一个字段A只有T和F两种值，且每一个值的分布几率大约为50%，那么对这种表A字段建索引通常不会提升数据库的查询速度。
   索引的选择性是指索引列中不一样值的数目与表中记录数的比。若是一张表中有2000条记录，表索引列有1980个不一样的值，那么这个索引的选择性就是1980/2000=0.99。一个索引的选择性越接近于1，这个索引的效率就越高。

性能分析

MySQL Query Optimizer

• MySQL中有专门负责优化SELECT语句的优化器模块，主要功能：经过计算分析系统中收集到的统计信息，为客户端请求的Query提供它认为最优的执行计划（它认为最优的数据检索方式，但不见得是DBA认为是最优的，这部分最耗费时间）。
• 当客户端向MySQL请求一条Query，命令解析器模块完成请求分类，区别出SELECT并转发给MySQL Query Optimizer时，MySQL Query Optimizer首先会对整条Query进行优化，处理掉一些常量表达式的预算，直接换算成常量值。并对Query中的查询条件进行简化和转换，如去掉一些无用或显而易见的条件、结构调整等。而后分析Query中的Hint信息（若是有），看现实Hint信息是否能够彻底肯定该Query的执行计划。若是没有Hint或Hint信息还不足以彻底肯定执行计划，则会读取所涉及对象的统计信息，根据Query进行写相应的计算分析，而后再得出最后的执行计划。

MySQL常见瓶颈

• CPU：CPU在饱和的时候通常发生在数据装入内存或从磁盘上读取数据的时候
• IO：磁盘I/O瓶颈发生在装入数据远大于内存容量的时候
• 服务器硬件的性能瓶颈：top, free, iostat和vmstat来查看系统的性能状态。

explain

What's this?

使用EXPLAIN关键字能够模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈。
官网介绍

What can it do?

• 表的读取顺序
• 数据读取操做的操做类型
• 哪些索引可使用
• 哪些索引被实际使用
• 表之间的引用
• 每张表有多少行被优化器查询

How to play?

• explain + SQL语句

• 包含的信息
  

• 各字段解释
  • id
select查询的序列号，包含一组数字，表示查询中执行select子句或操做表的顺序。包含三种状况：

    1. id相同，执行顺序由上至下
       

    2. id不一样，若是是子查询，id的序号会递增，id值越大优先级越高，越先被执行
       

    3. id相同和不一样，同时存在
       

    id若是相同，能够认为是一组，从上往下顺序执行，在全部组中，id值越大，优先级越高，越先执行。
  • select_type
    有6种类型：SIMPLE，PRIMARY，SUBQUERY，DERIVED，UNION，UNION RESULT，主要是用于区别普通查询、联合查询、子查询等复杂查询。
    1. SIMPLE：简单的select查询，查询中不包含子查询或者UNION
       
    2. PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记为PRIMARY
       
    3. SUBQUERY：在SELECT或者WHERE列表中包含了子查询
       
    4. DERIVED：在FROM列表中包含的子查询被标记为DERIVED（衍生），MySQL会递归执行这些子查询，把结果放在临时表里
       
    5. UNION：若第二个SELECT出如今UNION以后，则被标记为UNION，若UNION包含在FROM子句的子查询中，外层SELECT将被标记为：DERIVED
       
    6. UNION RESULT：从UNION表获取结果的SELECT
       
  • table
    显示这一行的数据是关于哪张表的。
  • type
    1. 主要有以下几种类型：ALL，index，range，ref，eq_ref，const,system，NULL。
       
    2. 访问类型排列：type显示的是访问类型，是较为重要的一个指标，结果值从最好到最坏依次是：
       system > const > eq_ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
       
    3. 显示查询了显示查询使用了何种类型，常见的以下，从最好到最差依次是：
       system > const > eq_ref > ref > range > index > ALL
       • system：表只有一行记录（等于系统表），这时const类型的特例，平时不会出现，这个也能够忽略不计
       • const：表示经过索引一次就找到了，const用于比较primary key或者unique索引，由于只匹配一行数据，因此很快，如将主键置于where列表中，MySQL就能将该查询转换为一个常量

       • eq_ref：惟一性索引扫描，对于每一个索引键，表中只有一条记录与之匹配。常见于主键或惟一索引扫描
         

       • ref：非惟一性索引扫描，返回匹配某个单独值的全部行。
         本质上也是上也是一种索引访问，它返回全部匹配某个单独值的行，然而，它可能会找到多个符合条件的行，因此它应该属于查找和扫描的混合体
         

       • range：只检索给定范围的行，使用一个索引来选择行。
         key列显示使用了哪一个索引，通常就是在你的where语句中出现了between、<、>、in等的查询，这种范围扫描索引扫描比全表扫描要好，由于它只须要开始于索引的某一点，而结束语另外一点，不用扫描所有索引。以下：
         

       • index：Full Index Scan，index与ALL的区别为index类型只遍历索引树，这一般比ALL块，由于索引文件一般比数据文件小。（也就是说虽然ALL和index都是读全表，但index是从索引中读取的，而ALL是从硬盘中读的）
       • ALL：Full Table Scan，将遍历全表以找到匹配的行
  • possible_keys
    显示可能应用在这张表中的索引，一个或多个。查询涉及到的字段上若存在索引，则该索引将被列出，但不必定被查询实际使用。

  • key
    实际使用的索引。若是为NULL，则没有使用索引。查询中若使用了覆盖索引，则该索引仅出如今key列表中。以下：
    先创建索引：
    create index idx_col1_col2 on t2(col1, col2);
    而后使用explain语句分析下列SQL语句:
    

  • key_len
    表示索引中使用的字节数，可经过该列计算查询中使用的索引的长度。在不损失精确性的状况下，长度越短越好，key_len显示的值为索引字段的最大可能长度，并不是实际使用长度，即key_len是根据表定义计算而得，不是经过表内检索出的。
  • ref
    显示索引的哪一列被使用了，若是可能的话，是一个常数。哪些列或常量被用于查找索引列上的值。以下：
    
    上图中，由key_len可知t1表的idx_col1_col2被充分使用，col1匹配t2表的col1，col2匹配了一个常量，即‘ac’。

  • rows
    根据表统计信息及索引选用状况，大体估算出找到所需的记录所须要读取的行数。以下，观察创建索引先后rows的变化：
    

  • Extra
    包含不适合在其余列中显示但十分重要的额外信息。id、type、key、rows、Extra是较为重要的。
    1. Using filesort：说明MySQL会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL中没法利用索引完成的排序操做称为“文件排序”。
       
       从上面两个例子能够看出，后者效率更高，若是出现Using filesort，该SQL语句会执行得比较慢，须要对其进行优化。
    2. Using temporary：使用了临时表保存中间结果，MySQL在对查询结果排序时使用临时表。临时表会很损耗性能。常见于排序order by和分组查询group by。
       
       若是出现了Using temporary，那么该SQL语句会更慢，需对其进行优化。
    3. Using index：表示相应的select操做中使用了覆盖索引（Covering Index），避免访问了表的数据行，效率不错！若是同时出现Using where，代表索引被用来执行索引键值的查找；若是没有同时出现Using where，代表索引被用来读取数据而非执行查找动做。
       
       若是同时出现Using where，代表索引被用来执行索引键值的查找；
       
       若是没有同时出现Using where，代表索引用来读取数据而非执行查找动做。
       覆盖索引（Covering Index），也称为索引覆盖。
       理解方式一：就是select的数据列只用从索引中就可以取得，没必要读取数据行，MySQL能够利用索引返回select列表中的字段，而没必要根据索引再次读取数据文件，换句话说查询列要被所建的索引覆盖。
       理解方式二：索引是高效找到行的一个方法，可是通常数据库也能使用索引找到一个列的数据，所以它没必要读取整个行。毕竟索引叶子节点存储了它们索引的数据；当能经过读取索引就能够获得想要的数据，那就不须要读取行了。一个索引包含了（或覆盖了）知足查询结果的数据就叫作覆盖索引。
       注意：若是要使用覆盖索引，必定要注意select列表中只取出须要的列，不可select *，由于若是将全部字段一块儿作索引会致使索引文件过大，查询性能降低。
    4. Using where：代表使用了where过滤。
    5. Using join buffer：使用了链接缓存。

    6. impossible where：where子句的值老是false，不能用来获取任何元组。如：
       

    7. select tables optimized away：（出现频率很小）在没有GROUP BY子句的状况下，基于索引优化MIN/MAX操做或者对于MyISAM存储引擎优化COUNT(*)操做，没必要等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。

    8. distinct：（出现频率很小）优化distinct操做，在找到第一匹配的元组后即中止找一样的动做。

CASE

第一行（执行顺序4）：id列为1，表示是union里的第一个select，select_type列的primary表示该查询为外层查询，table列被标记为<derived3>，表示查询结果里来自一个衍生表，其中derived3中3表明该查询衍生自第三个select查询，即id为3的select。select d1.name ......
第二行（执行顺序2）：id为3，是整个查询中第三个select的一部分，因查询包含在from中，因此为derived。select id, name from t1 where other_column="
第三行（执行顺序3）：select列表中的子查询select_type为subquery，为整个查询中的第二个select。select id from t3
第四行（执行顺序1）：select_type为union，说明第四个select是union里的第二个select，最早执行。select name, id from t2
第五行（执行顺序5）：表明从union的临时表中读取行的阶段，table列的<union1,4>表示用第一个和第四个select的结果进行。

索引优化

索引分析

1. 单表
   • 建表SQL
     
   • 案例
     查询category_id为1且comments大于1的状况下，views最多的article_id。
     explain select id, author_id from article where category_id = 1 and comments > 1 order by views desc limit 1;
     结论：很显然，type是ALL，即最坏的状况，Extra里还出现了Using filesort，也是最坏的状况。必需要进行优化。
     开始优化：
     • 新建索引
       alter table article add index idx_article_ccv(category_id, comments, views);或create index idx_article_ccv on article(category_id, comments, views);
       
     • 第2次EXPLAIN
       explain select id, author_id from article where category_id = 1 and comments > 1 order by views desc limit 1;
       
     结论：type为range，这是能够忍受的。可是extra里使用Using filesort还是没法接受的。
     可是咱们已经创建了索引，为啥没用呢？
     这是由于按照BTree索引的工做原理，先排序category_id，若是遇到相同的category_id，则再排序comments，若是遇到相同的comments则再排序views。
     当comments字段在联合索引里处于中间位置时，因comments > 1 条件是一个范围值（所谓range），MySQL没法利用索引再对后面的views部分进行检索，即range类型查询字段后面的索引无效。
     • 删除第一次创建的索引
       drop index idx_article_ccv on article;
       
     • 第2次新建索引
       alter table article add index idx_article_cv(category_id, views);或
       create index idx_article_cv on article(category_id, views);
       
     • 第3次explain
explain select id, author_id from article where category_id = 1 and comments > 1 order by views desc limit 1;
       
     结论：能够看到type变为了ref，Extra中的Using filesort也消失了，结果很是理想。
2. 两表
   • 建表SQL
     
   insert into class(card) values(floor(1 + (rand() * 20)));
insert into book(card) values(floor(1 + (rand() * 20)));
   添加数据，分别执行20次
   
   
   • 案例
     

   explain select * from class left join book on class.card = book.card;
   结论：type中有ALL。
   添加索引进行优化：alter table book add index y(card); 再次进行explain分析：
   
   能够看到第二行的type变为了ref，rows优化也比较明显。 这是由左链接特性决定的。left join条件用于肯定如何从右表搜索行，左边必定都有，因此右边是咱们的关键点，必定须要创建索引。
   删除旧索引，而后创建新的索引，再进行第3次explain

3. 三表
   • 建表SQL
     
   insert into phone(card) values(floor(1 + (rand() * 20)));
   添加数据，执行20次
   • 案例
     
     创建索引，进行优化：
     alter table phone add index z(card);
alter table book add index y(card);
     再看效果：
     

   后两行的type都是ref，且总的rows优化很好，效果不错，所以索引最好设置在须要常常查询的字段中。

Join语句的优化

• 尽量减小Join语句中的NestedLoop的循环总次数：“永远用小结果集驱动大的结果集”；
• 优先优化NestedLoop的内层循环；
• 保证Join语句中被驱动表上Join条件字段已经被索引；
• 当没法保证被驱动表的Join条件字段被索引且内存资源充足的前提下，不要太吝啬JoinBuffer的设置。

索引失效（应当避免）

• 建表SQL
  
  插入数据：
  insert into staffs(name, age, pos, add_time) values('z3', 22, 'manager', now());
insert into staffs(name, age, pos, add_time) values('july', 23, 'dev', now());
insert into staffs(name, age, pos, add_time) values('tom', 23, 'dev', now());
  
• 案例（索引失效）
  创建索引：ALTER TABLE staffs ADD INDEX idx_staffs_nameAgePos(name,age,pos);

  1. 全值匹配
     

  2. 最佳左前缀法则
     若是索引了多列，要遵照最左前缀法则。指的是查询从索引的最左前列开始而且不跳过索引中的列。（口诀：带头大哥不能死，中间兄弟不能断）

  3. 不在索引列上作任何操做（计算、函数、（自动or手动）类型转换），会致使索引失效而转向全表扫描
     

  4. 存储引擎不能使用索引中范围条件右边的列
     

  5. 尽可能使用覆盖索引（只访问索引的查询（索引列和查询列一致）），减小select *
  6. MySQL在使用不等于（!=或者< >）的时候没法使用索引会致使全表扫描
  7. is null，is not null也没法使用索引
  8. like以通配符开头（‘%abc…’）MySQL索引失效会变成全表扫描的操做
     问题：解决like '%字符串%'时索引不被使用的方法？
     
     在创建索引前，执行如下语句：
     explain select id from tbl_user where name like '%aa%;
explain select name from tbl_user where name like '%aa%;
explain select age from tbl_user where name like '%aa%;
explain select id, name from tbl_user where name like '%aa%;
explain select id, name, age from tbl_user where name like '%aa%;
explain select name, age from tbl_user where name like '%aa%;
explain select * from tbl_user where name like '%aa%;
explain select id, name, age, email from tbl_user where name like '%aa%;
     创建索引：create index idx_user_nameAge on tbl_user(name, age);
     在创建索引后，再执行上述explain，除了最后两条select *即查询列多出了索引外的email字段，其他都利用了覆盖索引或直接使用了主键索引，效果都会挺好。
  9. 字符串不加单引号索引失效
  10. 少用or，用它来链接时会索引失效

  11. 小总结
      全值匹配我最爱，最左前缀要遵照；
      带头大哥不能死，中间兄弟不能断；
      索引列上少计算，范围以后全失效；
      Like百分写最右，覆盖索引不写星；
      不等空值还有or，索引失效要少用；
      VAR引号不可丢，SQL高级也不难。

      假设index(a, b, c)：下表中的各类状况，可自行试验。

      where语句	索引是否被使用
      where a = 3	Y，使用到a
      where a = 3 and b = 5	Y，使用到a，b
      where a = 3 and b = 5 and c = 4	Y，使用到a，b，c
      where b = 3 或者 where b = 3 and c = 4 或者 where c = 4	N
      where a = 3 或者 c = 5	使用到a，可是c不能够，b中间断了
      where a = 3 and b > 4 and c = 5	使用到a和b，c不能用在范围以后，b断了
      where a = 3 and b like 'kk%' and c = 4	Y，使用到a，b，c
      where a = 3 and b like '%kk' and c = 4	Y，只用到a
      where a = 3 and b like '%kk%' and c = 4	Y，只用到a
      where a = 3 and b like 'k%kk%' and c = 4	Y，使用到a，b，c

• 通常性建议
  • 对于单值索引，尽可能选择针对当前query过滤性更好的索引
  • 在选择组合索引的时候，当前query中过滤性最好的字段在索引字段顺序中，位置越靠前越好。
  • 在选择组合索引的时候，尽可能选择能够可以包含当前query中的where子句中更多字段的索引
  • 尽量经过分析统计信息和调整query的写法来达到选择合适索引的目的。

查询优化

小表驱动大表

小表驱动大表，即小的数据集驱动大的数据集。

select * from A where id in (select id from B)
等价于
for select id from B
for select * from A where A.id = B.id

当B表的数据集必须小于A表的数据集时，用in优于exists。

select * from A where exists (select 1 from B where B.id = A.id)
等价于
for select * from A
for select * from B where B.id = A.id

当A表的数据集系小于B表的数据集时，用exists优于in。
注意：A表与B表的id字段应创建索引。

• exists
  select ... from table where exists (subquery);
  该语法能够理解为：将主查询的数据，放到子查询中作条件验证，根据验证结果（true或false）来决定主查询的结果数据是否得意保留。
• 提示
  • exists(subquery)只返回true或false，所以子查询中的select * 也能够是select 1 或其余，官方说法是实际执行时会忽略select清单，所以没有区别
  • exists子查询的实际执行过程可能通过了优化而不是咱们理解上的逐条对比，若是担心效率问题，可进行实际检验以肯定是否有效率问题
  • exists子查询每每也能够用条件表达式、其余子查询或者join来替代，何种最优须要具体问题具体分析

order by关键字优化

• order by子句，尽可能使用index方式排序，避免使用filesort方式排序

  1. 建表SQL + 添加数据 + 创建索引
     

  2. case
     

  3. MySQL支持两种方式的排序，filesort和index，index效率高，它指MySQL扫描索引自己完成排序，filesort方式效率较低
  4. order by知足两种状况，会使用index方式排序：
     • order by语句使用索引最左前列
     • 使用where子句与order by子句条件列组合知足索引最左前列
• 尽量在索引列上完成排序操做，遵守索引键的最佳左前缀
• 若是不在索引列上，filesort有两种算法，MySQL就要启动双路排序和单路排序
  1. 双路排序
     MySQL4.1以前是使用双路排序，字面意思就是两次扫描磁盘，最终获得数据，读取行指针和order by列，对他们进行排序，而后扫描已经排序好的列表，按照列表中的值从新从列表中读取对应的数据输出。
     从磁盘取排序字段，在buffer进行排序，再从磁盘取其余字段。
     取一批数据，要对磁盘进行了两次扫描，总所周知，I/O是很耗时的，因此在MySQL4.1以后，出现了第二种改进的算法，就是单路排序。
  2. 单路排序
     从磁盘读取查询须要的全部列，按照order by列在buffer对它们进行排序，而后扫描排序后的列表进行输出，它的效率更快一些，避免了第二次读取数据。而且把随机IO变成了顺序IO，可是它会使用更多的空间，由于它把每一行都保存在内存中了。
  3. 结论及引伸出的问题
     因为单路是后来出现的，整体而言好过双路。可是用单路有问题：
     在sort_buffer中，方法B比方法A要占用不少空间，由于方法B是把全部字段都取出，因此有可能取出的数据的总大小超出了sort_buffer的容量，致使每次只能取sort_buffer容量大小的数据，进行排序（建立tmp文件，多路合并），排完再去取sort_buffer容量大小，再排......从而屡次I/O。
     原本想省一次I/O操做，反而致使了大量的I/O操做，得不偿失。
• 优化策略
  1. 增大sort_buffer_size参数的的设置
  2. 增大max_length_for_sort_data参数的设置

why?

1. order by的时候，select *是一个大忌，所以只查询须要的字段，这点很是重要，在这里影响的是：
   • 当查询的字段大小总和小于max_length_for_sort_data并且排序字段不是text|blob类型时，会用改进后的算法--单路排序，不然用老算法--多路排序
   • 两种算法的数据都有可能超出sort_buffer的容量，超出以后，会建立tmp文件进行合并排序，致使屡次I/O，可是用单路排序算法的风险会更大一些，因此要提升sort_buffer_size
2. 尝试提升sort_buffer_size
   无论用哪一种算法，提升这个参数都会提升效率，固然，要根据系统的能力去提升，由于这个参数是针对每一个进程的
3. 尝试提升max_length_for_sort_data
   提升这个参数，会增长用改进算法的效率，可是若是设的过高，数据总容量超出sort_buffer_size的几率就增大，明显症状是高的磁盘I/O活动和低的处理器使用率

• 小总结
  key：a_b_c(a, b, c)

  order by能使用索引最左前缀
  order by a
  order by a,b
  order by a,b,c
  order by a desc,b desc,c desc #这个同时都为降序因此也能够

  若是where使用索引的最左前缀定义为常量，则order by能使用索引
  where a=const order by b,c
  where a=const and b=const order by c
  where a=const order by b,c
  where a=const and b>const order by b,c

  不能使用索引进行排序
  order by a asc,b desc,c desc #排序不一致，有升序有降序
  where g=const order by b,c #丢失a索引，没有带头大哥
  where a=const order by c #丢失b索引
  where a in(...) order by b,c #对于排序来讲，多个相等条件也是范围查询

group by关键字优化

• group by实质是先排序后进行分组，遵守索引建的最佳左前缀
• 当没法使用索引列，增大max_length_for_sort_data参数的设置加增大sort_buffer_size参数的设置
• where高于having，能写在where限定的条件就不要去having限定了

慢查询日志

What's this?

MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10秒以上的语句。
用它来查看哪些SQL超出了咱们的最大忍耐时间值，好比一条SQL执行超过5秒钟，咱们就把它定为慢SQL，但愿能收集超过5秒钟的SQL，结合以前的explain进行全面分析。

How to play?

• 说明
  默认状况下，MySQL数据库没有开启慢查询日志，须要咱们手动来设置这个参数。
  固然，若是不是调优须要的话，通常不建议启动该参数，由于开启慢查询日志会或多或少带来必定的性能影响。慢查询日志支持将日志记录写入文件。
• 查看是否开启及如何开启

  1. 默认
     show varialbes like '%slow_query_log%';
     经过执行上条语句，能够看到，默认状况下，slow_query_log的值为OFF，表示慢查询日志是禁用的。能够经过设置slow_query_log的值来开启。
     

  2. 开启
     set global slow_query_log=1;
     使用set global slow_query_log=1开启了慢查询日志，只对当前数据库生效，而且若是MySQL重启后则会失效。
     若是要永久生效，就必须修改配置文件my.cnf（其它系统变量也是如此）
     修改my.cnf文件，[mysqld]下增长或修改参数slow_query_log和slow_query_log_file后，而后重启MySQL服务器。也即，将以下两行配置进my.cnf文件
     slow_query_log=1
slow_query_log_file=/usr/local/mysql/data/chengchangfudeMacBook-Pro-slow.log
     关于慢查询的参数slow_query_log_file，它指定慢查询日志文件的存放路径，系统默认会给一个缺省的文件 host_name_slow.log（若是没有指定参数slow_query_log_file的话）。
• 开启了慢查询日志后，什么样的SQL才会记录到慢查询日志里面
  这个是由参数long_query_time控制的，默认状况下long_query_time的值为10秒，命令：show variables like 'long_query_time%';
  
  可使用命令修改，也能够在my.cnf参数里面修改。
  假如在运行时间正好等于long_query_time的状况，并不会被记录下来。也就是说，在MySQL源码里是判断大于long_query_time，而非大于等于。
• case
  1. 查看当前多少秒算慢日志
     show variables like 'long_query_time%';
  2. 设置慢日志的阈值时间
     set global long_query_time=3;
     修改后，须要从新链接数据库或新开一个会话才能看到修改值。

  3. 记录慢查询并分析
     
     

  4. 查询当前系统中有多少条慢查询记录
     

• 配置版
  [mysqld]下配置：
  

日志分析工具mysqldumpslow

在生产环境中，若是要手工分析日志，查找、分析SQL，显然是个体力活，MySQL提供了日志分析工具：mysqldumpslow。

• 查看mysqldumpslow的帮助信息
  使用mysqldumpslow --help命令进行查看

  s：是表示按照何种方式排序；
  c：访问次数
  l：锁定时间
  r：返回记录
  t：查询时间
  al：平均锁定时间
  ar：平均返回记录数
  at：平均查询时间
  t：即为返回前面多少条的数据；
  g：后边搭配一个正则匹配模式，大小写不敏感的；

• 工做经常使用参考

  获得返回记录集最多的10个SQL
  mysqlddumpslow -s r -t 10 chengchangfudeMacBook-Pro-slow.log
  获得访问次数最多的10个SQL
  mysqlddumpslow -s c -t 10 chengchangfudeMacBook-Pro-slow.log
  获得按照时间排序的前10条里面含有左链接的查询语句
  mysqlddumpslow -s t -t 10 -g "left join" chengchangfudeMacBook-Pro-slow.log
  另外建议在使用这些命令时结合|和more使用，不然有可能出现爆屏状况
  mysqlddumpslow -s r -t 10 chengchangfudeMacBook-Pro-slow.log | more

Show Profile

Show Profile是MySQL提供能够用来分析当前会话中语句执行的资源消耗状况。能够用于SQL调优的测量。
官网介绍
默认状况下，参数处于关闭状态，并保存最近15次的运行结果，使用set profiling=on;进行开启

• 运行SQL
  select * from emp group by id%10 limit 150000;
select * from emp group by id%20 order by 5;
• 查看结果
  

• 诊断SQL
  show profile cpu, block io for query 上一步前面的问题SQL数字号码;
  如：show profile cpu, block io for query 3;
  
  上面详细列出了一条查询语句通过的全部的过程。
  参数备注：

  ALL 显示全部的开销信息
  BLOCK IO 显示块IO相关开销
  CONTEXT SWITCHES 上下文切换相关开销
  CPU 显示CPU相关开销信息
  IPC 显示发送和接收相关开销信息
  MEMORY 显示内存相关开销信息
  PAGE FAULTS 显示页面错误相关开销信息
  SOURCE 显示和Source_function，Source_file，Source_line相关的开销信息
  SWAPS 显示交换次数相关开销信息

• 平常开发须要注意的结论
  若是出现下列状况，就糟糕了，就必须得对该条SQL语句进行优化。
  1. converting HEAP to MyISAM：查询结果太大，内存都不够用了往磁盘上搬了
  2. create tmp table：建立临时表，拷贝数据到临时表，用完再删除
  3. copying to tmp table on disk：把内存中临时表复制到磁盘，危险！！！
  4. locked