MySql面试精选 13-19
| 题号 | 题目 |
| 13 | Mysql如何保证一致性和持久性 |
| 14 | 为什么选择B+树作为索引结构 |
| 15 | InnoDB的行锁模式 |
| 16 | 哈希(hash)比树(tree)更快，索引结构为什么要设计成树型 |
| 17 | 为什么索引的key长度不能太长 |
| 18 | Mysql的数据如何恢复到任意时间点 |
| 19 | Mysql为什么加了索引可以加快查询 |
13. Mysql如何保证一致性和持久性
Mysql为了保证ACID中的一致性和持久性，使用了WAL(Write-Ahead Logging,先写日志再写磁盘)。Redo log就是一种WAL的应用。
当数据库忽然掉电，再重新启动时，Mysql可以通过Redo log还原数据。也就是说，每次事务提交时，不用同步刷新磁盘数据文件，只需要同步刷新Redo log就足够了。
14. 为什么选择B+树作为索引结构
- Hash索引：Hash索引底层是哈希表，哈希表是一种以key-value存储数据的结构，所以多个数据在存储关系上是完全没有任何顺序关系的，所以，对于区间查询是无法直接通过索引查询的，就需要全表扫描。所以，哈希索引只适用于等值查询的场景。而B+ 树是一种多路平衡查询树，所以他的节点是天然有序的（左子节点小于父节点、父节点小于右子节点），所以对于范围查询的时候不需要做全表扫描
- 二叉查找树：解决了排序的基本问题，但是由于无法保证平衡，可能退化为链表。
- 平衡二叉树：通过旋转解决了平衡的问题，但是旋转操作效率太低。
- 红黑树：通过舍弃严格的平衡和引入红黑节点，解决了AVL旋转效率过低的问题，但是在磁盘等场景下，树仍然太高，IO次数太多。
- B+树：在B树的基础上，将非叶节点改造为不存储数据纯索引节点，进一步降低了树的高度；此外将叶节点使用指针连接成链表，范围查询更加高效。此外, B+树, 主要是查询效率高，O(logN)，可以充分利用磁盘预读的特性，多叉树，深度小，叶子结点有序且存储数据.
15. InnoDB的行锁模式
- 共享锁(S)：用法lock in share mode，又称读锁，允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
- 排他锁(X)：用法for update，又称写锁，允许获取排他锁的事务更新数据，阻止其他事务取得相同的数据集共享读锁和排他写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。在没有索引的情况下，InnoDB只能使用表锁。
16. 哈希(hash)比树(tree)更快，索引结构为什么要设计成树型
加速查找速度的数据结构，常见的有两类：
- 哈希，例如HashMap，查询/插入/修改/删除的平均时间复杂度都是O(1)；
- 树，例如平衡二叉搜索树，查询/插入/修改/删除的平均时间复杂度都是O(lg(n))；
哈希只能满足等值查询, 不满足范围和大小查询, 其次哈希不可以排序.
Mysql是用等值查询,用树的话,等值查询只需要顺序遍历即可.
但是对于排序查询的sql需求：分组：group by ,排序：order by ,比较：<、>等,哈希型的索引，时间复杂度会退化为O(n)，而树型的“有序”特性，依然能够保持O(log(n)) 的高效率。
17. 为什么索引的key长度不能太长
key 太长会导致一个页当中能够存放的 key 的数目变少，间接导致索引树的页数目变多，索引层次增加，从而影响整体查询变更的效率。
18. Mysql的数据如何恢复到任意时间点
恢复到任意时间点以定时的做全量备份，以及备份增量的 binlog 日志为前提。恢复到任意时间点首先将全量备份恢复之后，再此基础上回放增加的 binlog 直至指定的时间点。
19. Mysql为什么加了索引可以加快查询
在数据十分庞大的时候，索引可以大大加快查询的速度，这是因为使用索引后可以不用扫描全表来定位某行的数据，而是先通过索引表找到该行数据对应的物理地址然后访问相应的数据。
索引的优缺点:
优势：可以快速检索，减少I/O次数，加快检索速度；根据索引分组和排序，可以加快分组和排序；
劣势：索引本身也是表，因此会占用存储空间，一般来说，索引表占用的空间的数据表的1.5倍；索引表的维护和创建需要时间成本，这个成本随着数据量增大而增大；构建索引会降低数据表的修改操作（删除，添加，修改）的效率，因为在修改数据表的同时还需要修改索引表.
