社招后端21连问（三年工作经验一面）（一）

前言

大家好，我是捡田螺的小男孩。有位朋友工作三年，去面试，给大家整理一下面试题，并附上答案。

 

1.Mysql索引在什么情况下会失效
2.MySql的存储引擎InnoDB与MyISAM的区别
3.Mysql在项目中的优化场景，慢查询解决等
4.Mysql有什么索引，索引模型是什么
5.B-树与B+树的区别？为什么不用红黑树
6.Mysql主从同步怎么做
7.乐观锁与悲观锁的区别？
8.聊聊binlog日志
9.redis 持久化有哪几种方式，怎么选？
10.redis 主从同步是怎样的过程？
11.redis 的 zset 怎么实现的？
12.Redis 过期策略和内存淘汰策略
13.Hashmap实现原理
14.select 和 epoll的区别
15.http与https的区别，https的原理，如何加密的？
16.Raft算法原理
17.消息中间件如何做到高可用
18.消息队列怎么保证不丢消息的
19.聊聊Redis的哨兵机制
20.算法题：无重复字符的最长子串

 

1. Mysql索引在什么情况下会失效

 •  查询条件包含or，可能导致索引失效
 •  如何字段类型是字符串，where时一定用引号括起来，否则索引失效
 •  like通配符可能导致索引失效。
 •  联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
 •  在索引列上使用mysql的内置函数，索引失效。
 •  对索引列运算（如，+、-、*、/），索引失效。
 •  索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。
 •  索引字段上使用is null， is not null，可能导致索引失效。
 •  左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。
 •  mysql估计使用全表扫描要比使用索引快,则不使用索引。

2. MySql的存储引擎InnoDB与MyISAM的区别

 •  InnoDB支持事务，MyISAM不支持事务
 •  InnoDB支持外键，MyISAM不支持外键
 •  InnoDB 支持 MVCC(多版本并发控制)，MyISAM 不支持
 •  select count(*) from table时，MyISAM更快，因为它有一个变量保存了整个表的总行数，可以直接读取，InnoDB就需要全表扫描。
 •  Innodb不支持全文索引，而MyISAM支持全文索引（5.7以后的InnoDB也支持全文索引）
 •  InnoDB支持表、行级锁，而MyISAM支持表级锁。
 •  InnoDB表必须有主键，而MyISAM可以没有主键
 •  Innodb表需要更多的内存和存储，而MyISAM可被压缩，存储空间较小。
 •  Innodb按主键大小有序插入，MyISAM记录插入顺序是，按记录插入顺序保存。
 •  InnoDB 存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全，与 MyISAM 比 InnoDB 写的效率差一些，并且会占用更多的磁盘空间以保留数据和索引

 

3. mysql在项目中的优化场景，慢查询解决等

我们面对慢查询，首先想到的就是加索引。你可以给面试官描述一下，一个加了索引的SQL，是怎么执行查找的，可以看下我之前这篇文章哈：

 

阿里一面，给了几条SQL，问需要执行几次树搜索操作？

 

还有就是order by，group by原理，深分页等等，都跟慢查询息息相关，大家可以看下我以前的文章哈，都比较经典：

 

 •  看一遍就理解：order by详解
 •  看一遍就理解：group by详解
 •  实战！聊聊如何解决MySQL深分页问题
 •  后端程序员必备：书写高质量SQL的30条建议

最后就是慢查询的排查解决手段：

 

打开慢查询日志slow_query_log，确认SQL语句是否占用过多资源，用explain查询执行计划、对group by、order by、join等语句优化，如果数据量实在太大，是否考虑分库分表等等。

 

4. Mysql有什么索引，索引模型是什么
数据结构维度来讲的话，一般使用都是B+树索引，大家想详细理解的话，可以看我之前这篇文章哈：MySQL索引底层：B+树详解

 

5. B-树与B+树的区别？为什么不用红黑树

B-树与B+树的区别：

 

 •  B-树内部节点是保存数据的;而B+树内部节点是不保存数据的，只作索引作用，它的叶子节点才保存数据。
 •  B+树相邻的叶子节点之间是通过链表指针连起来的，B-树却不是。
 •  查找过程中，B-树在找到具体的数值以后就结束，而B+树则需要通过索引找到叶子结点中的数据才结束
 •  B-树中任何一个关键字出现且只出现在一个结点中，而B+树可以出现多次。

为什么索引结构默认使用B+树，而不是B-Tree，Hash哈希，二叉树，红黑树？

 

 •  Hash哈希，只适合等值查询，不适合范围查询。
 •  一般二叉树，可能会特殊化为一个链表，相当于全表扫描。
 •  红黑树，是一种特化的平衡二叉树，MySQL 数据量很大的时候，索引的体积也会很大，内存放不下的而从磁盘读取，树的层次太高的话，读取磁盘的次数就多了。
 •  B-Tree，叶子节点和非叶子节点都保存数据，相同的数据量，B+树更矮壮，也是就说，相同的数据量，B+树数据结构，查询磁盘的次数会更少。

 

6. Mysql主从同步怎么做

大家要熟悉MySQL主从复制原理哈：

 

详细的主从复制过程如图：上图主从复制过程分了五个步骤进行：

 

1.主库的更新SQL(update、insert、delete)被写到binlog
2.从库发起连接，连接到主库。
3.此时主库创建一个binlog dump thread，把binlog的内容发送到从库。
4.从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log
5.从库还会创建一个SQL线程，从relay log里面读取内容，从ExecMasterLog_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

 

主从同步这块呢，还涉及到如何保证主从一致的、数据库主从延迟的原因与解决方案、数据库的高可用方案。

 

大家可以看下我最近的一篇总结哈：面试必备：聊聊MySQL的主从

 

7. 乐观锁与悲观锁的区别？

悲观锁：

 

悲观锁她专一且缺乏安全感了，她的心只属于当前事务，每时每刻都担心着它心爱的数据可能被别的事务修改，所以一个事务拥有（获得）悲观锁后，其他任何事务都不能对数据进行修改啦，只能等待锁被释放才可以执行。select ...for update就是悲观锁一种实现。

 

乐观锁：

 

乐观锁的“乐观情绪”体现在，它认为数据的变动不会太频繁。因此，它允许多个事务同时对数据进行变动。实现方式：乐观锁一般会使用版本号机制或CAS算法实现。之前用乐观锁解决过实战的并发问题，大家有兴趣可以加我微信，一起聊聊哈。

 

8. 聊聊binlog日志

binlog是归档日志，属于MySQL Server层的日志。可以实现主从复制和数据恢复两个作用。当需要恢复数据时，可以取出某个时间范围内的binlog进行重放恢复即可。

 

binlog 日志有三种格式，分别是statement，row和mixed。

 

如果是statement格式，binlog记录的是SQL的原文，他可能会导致主库不一致(主库和从库选的索引不一样时)。我们来分析一下。假设主库执行删除这个SQL（其中a和create_time都有索引）如下：

delete from t where a > '666' and create_time<'2022-03-01' limit 1;

我们知道，数据选择了a索引和选择create_time索引，最后limit 1出来的数据一般是不一样的。所以就会存在这种情况：在binlog = statement格式时，主库在执行这条SQL时，使用的是索引a，而从库在执行这条SQL时，使用了索引create_time。最后主从数据不一致了。

 

如何解决这个问题呢？

 

可以把binlog格式修改为row。row格式的binlog日志，记录的不是SQL原文，而是两个event:Table_map 和 Delete_rows。Table_map event说明要操作的表，Delete_rows event用于定义要删除的行为，记录删除的具体行数。row格式的binlog记录的就是要删除的主键ID信息，因此不会出现主从不一致的问题。

 

但是如果SQL删除10万行数据，使用row格式就会很占空间的，10万条数据都在binlog里面，写binlog的时候也很耗IO。但是statement格式的binlog可能会导致数据不一致，因此设计MySQL的大叔想了一个折中的方案，mixed格式的binlog。所谓的mixed格式其实就是row和statement格式混合使用，当MySQL判断可能数据不一致时，就用row格式，否则使用就用statement格式。