大家好,我是捡田螺的小男孩。有位朋友工作三年,去面试,给大家整理一下面试题,并附上答案。
- Mysql索引在什么情况下会失效
- MySql的存储引擎InnoDB与MyISAM的区别
- Mysql在项目中的优化场景,慢查询解决等
- Mysql有什么索引,索引模型是什么
- B-树与B+树的区别?为什么不用红黑树呢
- Mysql主从同步怎么做
- 乐观锁与悲观锁的区别?
- 聊聊binlog日志
- redis 持久化有哪几种方式,怎么选?
- redis 主从同步是怎样的过程?
- redis 的 zset 怎么实现的?
- Redis 过期策略和内存淘汰策略
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主从复制原理哈:
详细的主从复制过程如图:
上图主从复制过程分了五个步骤进行:
- 主库的更新SQL(update、insert、delete)被写到binlog
- 从主库发起连接,连接到主库。
- 此时主库创建一个binlog dump thread,把binlog的内容发送到从库。
- 从库启动之后,创建一个I/O线程,读取主库传过来的bin log内容并写入到relay log
- 从库还会创建一个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。最后主从数据不一