想要让面试官觉得你很懂MySQL，看这篇多写一个熟悉InnoDB

上面提到的Hash索引是什么，能展开讲讲吗

哈希索引对于每一行数据计算一个哈希码，并将所有的哈希码存储在索引中，同时在哈希表中存储指向每个数据行的指针。只有Memory引擎显式支持哈希索引。

Hash索引相较于B+树的缺点是不支持范围查询，无法用于排序，也不支持部分索引列匹配查找。

自适应Hash索引

现在还在使用的是使用Hash索引对于B-Tree的优化，InnoDB对于某些频繁使用的某些索引值，会在内存中基于B-Tree索引之上在创建一个哈希索引，承做自适应Hash索引。

聚集索引和稀疏索引

聚集索引按每张表的主键构建一棵B+树，数据库中的每个搜索键值都有一个索引记录，每个数据也通过双向链表连接。表数据访问更快，但表更新代价高。

稀疏索引不会为每个搜索关键字创建索引记录。搜索过程中，首先按索引记录进行操作，并按顺序搜索，直到找到所需的数据为止。

辅助索引与回表查询

辅助索引是非聚集索引，叶子节点不包含记录的全部数据，包含了一个书签来告诉InnoDB哪里可以找到与索引相对应的行数据。

通过辅助索引查询，先通过书签查询到聚集索引，再根据聚集索引查对应的值，需要两次，也称为回表查询。

简述联合索引和最左匹配原则

联合索引是指对表上的多个列的关键词进行索引。

对于联合索引的查询，如果精确匹配联合索引的左边连续一列或者多列，则mysql会一直向右匹配直到遇到范围查询（>,<,between,like）就停止匹配。Mysql会对第一个索引字段数据进行排序，在第一个字段基础上，再对第二个字段排序。

简述覆盖索引

覆盖索引指一个索引包含或覆盖了所有需要查询的字段的值，不需要回表查询，即索引本身存了对应的值。

为什么数据库不用红黑树而用B+树

红黑树的出度为2，而BTree的出度一般都非常大。红黑树的树高h很明显比Btree大非常多，IO次数很多，导致会比较慢，因此检索的次数也就更多。

B+树相比于B-Tree更适合外存索引，拥有更大的出度，IO次数较少，检索效率更高。

基于主键索引的查询和非主键索引的查询有什么区别？

对于select*from 主键==XX，基于主键的普通查询仅查找主键这棵树，对于select*from非主键=XX，基于非主键的查询有可能存在回表过程（回到主键索引树搜索的过程成为回表），因为非主键索引叶子节点仅存在主键值，无整行全部信息。

非主键索引的查询一定会回表吗？

不一定，当查询语句的要求字段全部命中索引，不用回表查询。如select主键from非主键=XX，此时非主键索引叶子节点即可拿到主键信息，不用回表。

简述MySQL使用EXPLAIN的关键字段

explain关键字用于分析sql语句的执行情况，可以通过它进行sql语句的性能分析。

type：表示连接类型，从好到差的类型排序为

        sysytem->const->eq_ref->ref->range->index->all

key：显示MySQL实际使用的键。

key_len：显示MySQL决定使用的键长度，长度越短越好。

Extra：额外信息

        Using filesort：MySQL使用外部的索引排序，很慢，需要优化

        Using temporary：使用了临时表保存中间结果，很慢需要优化。

        Using index：使用了覆盖索引。

        Using where：使用了where。

简述MySQL优化流程：

        1.通过慢日志定位执行较慢的SQL语句。

        2.利用explain对这些关键字段进行分析

        3.根据分析结果进行优化

简述MySQL中的日志log

redo log：存储引擎级别的log（InnoDB有，MyISAM没有），该log关注于事务的恢复。在重启mysql服务的时候，根据redo log进行重做，从而使事务有持久性。

undo log：存储引擎级别的log（InnoDB有，MyISAM没有），保证数据的原子性，该log保存了事务发生之前的数据的一个版本，可以用于回滚，是MVCC的重要实现方法之一。

bin log：数据库级别的log，关注恢复数据库的数据。

简述事务

事务内的语句要么全部执行成功，要么全都不执行。

ACID

原子性（Atomicity）事务作为一个整体，类比于化学中的原子作为执行功能的最小单位。里面的所有SQL语句要么全都执行成功，要么全部不完成。

一致性（Consistency）事务执行完之后，要么对数据库产生了持久性的影响，要么未对数据库产生任何影响。

隔离性（Isolation）多个并发事务对数据库进行操作时，事务间互不干扰。

持久性（Durability）前三个特性都是为了第四条特性得以实现而存在的，即事务执行完毕，对数据的修改是永久的，即使系统发生故障也不会丢失。

数据库中多个事务同时进行肯能会出现什么问题？

        丢失修改

        脏读：当前事务可以查看到别的事务未提交的数据

        不可重复读：在同一事务中，使用相同的查询语句，同一数据资源莫名改变了

        幻读：在同一事务中，使用相同的查询语句，莫名出现了一些之前不存在的数据，或莫名少了一些原先存在的数据。

SQL的事务隔离级别有哪些？

RU read uncommitted,RC read committed,RR repeatable read,S serializable

读未提交（RU）：一个事务还未提交，它做的改变就能被别的事务看到。

读提交（RC）：一个事务提交后，它做的改变才能被别的事务看到。

可重复读（RR)：一个事务执行过程中看到的数据总是和事务启动时看到的数据是一致的。在这个级别下事务未提交，做出的变更其他事务也看不到。

串行化（S）：对于同一记录进行读写会分别加读写锁，当发生读写锁冲突，后面执行的事务徐等前面执行的事务完成才能继续执行。

什么是MVCC

多版本并发控制，即同一条记录在系统中存在多个版本。其存在目的是在保证数据一致性的前提下提供一种高并发的访问性能。对数据读写在不加锁的情况下实现互不干扰，从而实现数据库的隔离性，在事务隔离级别为读提交和可重复读中使用到。

RC和RR都基于MVCC实现，有什么区别？

在可重复读级别下，只会在事务开始前创建视图，事务中后续的查询共用一个视图。而读提交级别下每个语句执行前都会创建新的视图。因此对于可重复读，查询只能看到事务创建前就已经提交的数据。而遂于读提交，查询能看到每个语句启动前已经提交的数据。

InnoDB如何保证事务的特性

undo log保障原子性。该log保存了事务发生前数据的一个版本，可以用于回滚，从而保证事物的原子性。

redo log保障持久性。该log关注于事物的恢复，在重启mysql服务的时候，根据redo log进行重做，从而使事务有持久性。

利用undo log和redo log保障一致性。事务中的执行需要redo log，如果执行失败，需要undo log回滚。

MySQL如何保证主备一致性？

通过binlog（二进制日志）实现主备一致。binlog记录了所有修改数据库或可能修改数据库的语句。在备份的过程中，主库A会有一个专门的线程将主库A的binlog发送给备库B进行备份。

redo log和binlog的区别

crash-safe能力

InnoDB通过redo log保证即使数据库发生异常重启，之前提交的记录都不会丢失。

WAL技术

Write-Ahead Logging，关键点是先写日志，再写磁盘。事务在提交写入磁盘前，会先写到redo log里面去。如果直接写入磁盘的随机I/O访问，涉及磁盘随机I/O访问是非常消耗时间的一个过程，相比之下先写入redo log ，后面再找合适的时机批量刷盘提升性能。

两阶段提交

为了保证binlog和redo log两份日志的逻辑一致，最终保证恢复到主备数据库的数据是一致的，采用两阶段提交的机制。

1. 执行器调用存储引擎接口，存储引擎将修改更新到内存中后，将修改操作记录redo log中，此时 redo log处于prepare状态。

2. 存储引擎告知执行器执行完毕，执行器生成这个操作对应的binlog，并把binlog写入磁盘。

3. 执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交commit状态，更新完成。

只靠binlog可以支持数据库崩溃恢复吗？

InnoDB在作为MySQL的插件加入MySQL引擎家族之前，就已经是一个提供了崩溃恢复和事务支持的引擎了。binlog没有记录数据页修改的详细信息，不具备恢复数据页的能力。操作写入binlog可细分为write和sync两个过程，通过参数设置sync_binlog为0的时候，表示每次提交事务都只write不sync，此时数据库崩溃可能导致部分提交的事务以及binlog日志由于没有持久化而丢失。

简述MySQL主从复制

方便与实现数据的多处自动备份，不仅能增加数据库的安全性，还能进行读写分离，提升数据库负载性能。只在主库中写，只在从库中读，以减少数据压力，提高性能。