1.MySQL 索引底层结构为什么使用 B+树？
- 哈希虽然能够提供 O(1) 的单数据行操作性能，但是对于范围查询和排序却无法很好地支
持，最终导致全表扫描；B 树能够在非叶节子点中存储数据，但是这也导致在查询连续数
据时可能会带来更多的随机 I/O，而 B+树的所有叶节点可以通过指针相互连接，能够减
少顺序遍历时产生的额外随机 I/O； - 第一，B 树一个节点里存的是数据，而 B+树存储的是索引（地址），所以 B 树里一个节
点存不了很多个数据，但是 B+树一个节点能存很多索引，B+树叶子节点存所有的数据。 - 第二，B+树的叶子节点是数据阶段用了一个链表串联起来，便于范围查找。
2.MVCC 是什么？它的底层原理是什么？
MVCC，多版本并发控制,它是通过读取历史版本的数据，来降低并发事务冲突，从而提高并
发性能的一种机制。
- 事务版本号
- 表的隐藏列
- undo log
- read view
3.索引失效的情况有哪些？
- like 以%开头索引无效，当 like 以&结尾，索引有效。
- or 语句前后没有同事使用索引，当且仅当 or 语句查询条件的前后列均为索引时，索引生
效。 - 组合索引，使用的不是第一列索引时候，索引失效，即最左匹配规则。
- 数据类型出现隐式转换，如 varchar 不加单引号的时候可能会自动转换为 int 类型，这个
时候索引失效。 - 在索引列上使用 IS NULL 或者 IS NOT NULL 时候，索引失效，因为索引是不索引空值
得。 - 在索引字段上使用，NOT、 <>、！= 、时候是不会使用索引的，对于这样的处理只会进
行全表扫描。 - 对索引字段进行计算操作，函数操作时不会使用索引。
- 当全表扫描速度比索引速度快的时候不会使用索引。
4.Redis 主从同步是怎么实现的？
全量同步
master 服务器会开启一个后台进程用于将 redis 中的数据生成一个 rdb 文件，与此同时，服
务器会缓存所有接收到的来自客户端的写命令（包含增、删、改），当后台保存进程处理完毕后，会将该 rdb 文件传递给 slave 服务器，而 slave 服务器会将 rdb 文件保存在磁盘并通过读
取该文件将数据加载到内存，在此之后 master 服务器会将在此期间缓存的命令通过 redis 传输协议发送给 slave 服务器，然后 slave 服务器将这些命令依次作用于自己
本地的数据集上最终达到数据的一致性。
增量同步
从 redis 2.8 版本以前，并不支持部分同步，当主从服务器之间的连接断掉之后，master 服务
器和 slave 服务器之间都是进行全量数据同步。
从 redis 2.8 开始，即使主从连接中途断掉，也不需要进行全量同步，因为从这个版本开始融
入了部分同步的概念。部分同步的实现依赖于在 master 服务器内存中给每个 slave 服务器维
护了一份同步日志和同步标识，每个 slave 服务器在跟 master 服务器进行同步时都会携带自
己的同步标识和上次同步的最后位置。当主从连接断掉之后，slave 服务器隔断时间（默认
1s）主动尝试和 master 服务器进行连接，如果从服务器携带的偏移量标识还在 master 服务
器上的同步备份日志中，那么就从 slave 发送的偏移量开始继续上次的同步操作，如果 slave
发送的偏移量已经不再 master 的同步备份日志中（可能由于主从之间断掉的时间比较长或者
在断掉的短暂时间内 master 服务器接收到大量的写操作），则必须进行一次全量更新。在部
分同步过程中，master 会将本地记录的同步备份日志中记录的指令依次发送给 slave 服务器
从而达到数据一致。
Redis 主从同步策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，
slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同
步，如不成功，要求从机进行全量同步。
