Mysql默认搜索引擎

Mysql5.5以后默认使用InnoDB为搜索引擎

MyISAM是表锁，不支持事务和主外键

InnoDB默认可以创建16个索引

• InnoDB支持事务，MyIsam不支持事务，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放到begin 和 commit之间，组成一个事务；
• InnoDB支持外键，而MyIsam不支持，对一个包含外键的InnoDB表转成MyIsam表会失败
• InnoDB是聚集索引，数据文件和索引绑定在一块，必须要有主键，通过主键索引效率很高，但是辅助索引需要两次查询，先查询到主键，然后在通过主键查询到数据。因此主键不应该过大。主键过大的时候，其它索引也会很大。而MyIsam是非聚集索引，数据和文件是分离的，索引保存的是数据文件的指针，主键索引和辅助索引是独立的。
• InnoDB不支持全文检索，而MyIsam支持全文检索，查询效率上MyIsam要高

硬盘

Mysql是存储在硬盘上，因此Redis比Mysql快

索引(mysql必问)

Mysql官方对索引的定位为：索引是能快速排序的数据结构。

可以简单的理解为：排好序的快速查找B+树数据结构，B+树中的B代表平衡(balance)

聚簇索引和非聚簇索引

• 聚簇索引：将数据存储与索引放到一块，索引结构的叶子节点保存了行数据
• 非聚簇索引：将数据与索引分开，索引结构的叶子节点指向了数据对应的位置

在InnoDB中，在聚簇索引之上创建的索引被称为辅助索引，非聚簇索引都是辅助索引，像复合索引，前缀索引，唯一索引。辅助索引叶子节点存储不再是行的物理位置，而是主键值，辅助索引访问数据总是需要二次查找，这个就被称为 回表操作

InnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用"where id = 14"这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据。

若对Name列进行条件搜索，则需要两个步骤：第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作，最终到达叶子节点即可获取整行数据。（重点在于通过其他键需要建立辅助索引）

MyISAM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。（MylSAM目前没有问到，仅了解就行）

使用聚簇索引的优势（了解）

**每次使用辅助索引检索都要经过两次B+树查找，**看上去聚簇索引的效率明显要低于非聚簇索引，这不是多此一举吗？聚簇索引的优势在哪？

1.由于行数据和聚簇索引的叶子节点存储在一起，同一页中会有多条行数据，访问同一数据页不同行记录时，已经把页加载到了Buffer中（缓存器），再次访问时，会在内存中完成访问，不必访问磁盘。这样主键和行数据是一起被载入内存的，找到叶子节点就可以立刻将行数据返回了，如果按照主键Id来组织数据，获得数据更快。

2.辅助索引的叶子节点，存储主键值，而不是数据的存放地址。好处是当行数据放生变化时，索引树的节点也需要分裂变化；或者是我们需要查找的数据，在上一次IO读写的缓存中没有，需要发生一次新的IO操作时，可以避免对辅助索引的维护工作，只需要维护聚簇索引树就好了。另一个好处是，因为辅助索引存放的是主键值，减少了辅助索引占用的存储空间大小。

注：我们知道一次io读写，可以获取到16K大小的资源，我们称之为读取到的数据区域为Page。而我们的B树，B+树的索引结构，叶子节点上存放好多个关键字（索引值）和对应的数据，都会在一次IO操作中被读取到缓存中，所以在访问同一个页中的不同记录时，会在内存里操作，而不用再次进行IO操作了。除非发生了页的分裂，即要查询的行数据不在上次IO操作的换村里，才会触发新的IO操作。

3.因为MyISAM的主索引并非聚簇索引，那么他的数据的物理地址必然是凌乱的，拿到这些物理地址，按照合适的算法进行I/O读取，于是开始不停的寻道不停的旋转。聚簇索引则只需一次I/O。（强烈的对比）

4.不过，如果涉及到大数据量的排序、全表扫描、count之类的操作的话，还是MyISAM占优势些，因为索引所占空间小，这些操作是需要在内存中完成的。

聚簇索引需要注意的地方（容易问到）

当使用主键为聚簇索引时，主键最好不要使用uuid，因为uuid的值太过离散，不适合排序且可能出线新增加记录的uuid，会插入在索引树中间的位置，导致索引树调整复杂度变大，消耗更多的时间和资源。

建议使用int类型的自增，方便排序并且默认会在索引树的末尾增加主键值，对索引树的结构影响最小。而且，主键值占用的存储空间越大，辅助索引中保存的主键值也会跟着变大，占用存储空间，也会影响到IO操作读取到的数据量。

为什么主键通常建议使用自增id

聚簇索引的数据的物理存放顺序与索引顺序是一致的，即：只要索引是相邻的，那么对应的数据一定也是相邻地存放在磁盘上的。如果主键不是自增id，那么可以想 象，它会干些什么，不断地调整数据的物理地址、分页，当然也有其他一些措施来减少这些操作，但却无法彻底避免。但，如果是自增的，那就简单了，它只需要一 页一页地写，索引结构相对紧凑，磁盘碎片少，效率也高。

Mysql为什么是B+树

B+树中，所有数据记录节点都是按照键值大小顺序存放在同一层叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+树的高度。

• InnoDB存储引擎的最小存储单元是页，页可以用于存放数据，也可以用于存放键值+指针，在B+树中叶子节点存放数据，而非叶子节点存放键值+指针
• 索引组织表通过非叶子节点的二分查找法以及指针确定数据在哪个页中，首先找到根页进而去数据页查找到需要的数据

B+树算法：通过集成B树的特征，B+树相比B树，新增叶子节点与非叶子节点关系，叶子节点包含了键值和数据，非叶子节点只是包含键值和子节点引用，不包含数据。

通过非叶子节点查询叶子节点获取相应的数据，所有相邻的叶子节点包含非叶子节点使用链表进行结合，叶子节点是顺序并且相邻节点有顺序引用关系。

支持范围查询的原因是因为底部是双向链表

底层原理

数据库索引是存储在磁盘上的，如果数据很大，必然导致索引的大小也会很大，超过几个G（好比新华字典字数多必然导致目录厚）

当我们利用索引查询时，是不可能将全部几个G的索引都加载进内存的，我们能做的只能是：

逐一加载每一个磁盘页，因为磁盘页对应着索引树的节点。

InnoDB的 page_size

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

系统从磁盘读取数据到内存时是以磁盘块（block）为单位的，位于同一磁盘块中的数据会被一次性读取出来，而不是需要什么取什么

InnoDB存储引擎中有页(Page)的概念，页是其磁盘管理的最小单位。

系统一个磁盘块的存储空间往往没有这么大，因此InnoDB每次申请磁盘空间时都会是若干地址连续磁盘块来达到页的大小16KB。InnoDB在把磁盘数据读入到磁盘时会以页为基本单位，在查询数据时如果一个页中每条数据都有助于定位数据记录的位置，这将会减少磁盘I/O次数，提高效率。

一句话说：就是多个块填充到一页大小

最左前缀原则(重要)

最左前缀原则主要使用在联合索引中

给a,b,c加上索引，那么a,b可以用到索引，a,c也可以用到索引，但b,c是用不到的。包括这个a必须要在用到的第一个索引处。但是如果一个表中只有a,b,c三个字段，给他们加上联合索引（a,b,c）。

索引失效

1、组合索引，不是使用第一列索引，索引失效

2、like 已通配符开头（%abc）导致索引失效 （解决方法：使用覆盖索引）

3、or语句前后没有同时使用索引。当or左右查询字段只有一个是索引，该索引失效，只有当or左右查询字段均为索引时，才会生效

4、使用 is null 或者 is not null 也不能使用索引

5、使用不等于（！= 或者<>）不能使用索引

6、不要在索引列上做任何操作

7、如果在索引上加上一些sql的操作会使索引失效,前提是其中一个索引不是id,如果是的话是可以做一些简单的操作的

索引调优

使用explain+sql语句进行调优

explain 包含的信息包含： 主要从 id、type、key、rows、Extra 分析。

id 表示执行的先后顺序，id 值大的先执行，小的后执行，id 值相同的从上到下执行。type

访问类型，结果值从好到坏依次是：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL。

　　　建议尽量达到 range 级别，常见类型介绍如下：

const：通过索引一次找到，通常用于主键或唯一性索引。

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

ref：非唯一性索引扫描，返回匹配某个单独值的所有行。

range：只检索给定范围的行，使用一个索引来选择行。key列显示使用了那个索引。一般就是在where语句中出现了bettween、<、>、in等的查询。

index：Index与ALL虽然都是读全表，但index是从索引中读取，而ALL是从硬盘读取。

ALL: Full Table Scan，全表扫描 。

key

　　　　实际使用的索引，如果为NULL，则没有使用索引。查询中如果使用了覆盖索引，则该索引仅出现在key列表中 。

rows

　　　　根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数。

Extra

Using index： 表示相应的 select 操作中使用了覆盖索引（Covering Index），避免了访问表的数据行，效率高 。Using where，表明索引被用来执行索引键值的查找，如果没用同时出现 Using where，表明索引用来读取数据而非执行查找动作。

Using where：表示使用了where条件过滤。

Convering Index：覆盖索引表示直接从索引中读取数据，sql中查询字段、where条件等涉及的字段都在覆盖索引包含的字段里面。

Using Index Condition：优化器在索引存在情况下通过符合range范围的条数和总数比例来确定进行索引还是全表遍历。

Using filesort：无法利用索引完成的排序操作。

Using temporary：使用临时表保存中建结果，如order by和group by，出现临时表需要优化sql。

数据库调优

mysql库主从读写分离。

SQL语句及索引的优化

1. 使用连接(JOIN)来代替子查询
2. 适用联合(UNION)来代替手动创建的临时表

数据库表结构的优化

找规律分表，减少单表中的数据量提高查询速度。