MySQL夺命连环15问,你能坚持到第几问?
Posted JinziH Never Give Up
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL夺命连环15问,你能坚持到第几问?相关的知识,希望对你有一定的参考价值。
文章目录
- 前言
- 一、关系型和非关系型的区别,以及使用场景
- 二、Mysql索引优缺点
- 三、给字段加索引最好怎么加?
- 四、什么情况下会导致索引失效?
- 五、为什么使用模糊匹配会使索引失效
- 六、回表查询和索引覆盖是什么
- 七、联合索引的好处是什么
- 八、MySQL怎么判断走索引还是全表扫描
- 九、Explain语句结果中各个字段分别表示什么
- 十、Mysql慢查询该如何优化?
- 十一、左匹配,右匹配,inner join说一下区别
- 十二、你对使用外键怎么看?
- 十三、说一下脏读、不可重复读以及幻读是什么
- 十四、说说select ... 这个查询语句,在mysql查询的过程
- 十五、说说redo log和undo log 日志的过程
- 总结
前言
本篇文章中列出的有关MySQL的问题,都是作者在平时学习中遇到或者面试中被问到的问题,针对每个问题作者都做了自己的梳理和总结,整篇文章内容很丰富,希望能给读者带来实际的帮助。
一、关系型和非关系型的区别,以及使用场景
关系型数据库 :采用关系模型来组织数据的数据库,关系模型就是二维表格模型。一张二维表的表名就是关系,二维表中的一行就是一条记录,二维表中的一列就是一个字段
优点:容易理解 ,使用方便,通用的 sql 语言 ,易于维护,丰富的完整性(实体完整性、参照完整性和用户定义的完整性)
缺点:磁盘 I/O 是并发的瓶颈 ,海量数据查询效率低 ,横向扩展困难,无法简单的通过添加硬件和服务节点来扩展性能和负载能力, 需要对数据库进行升级和扩展时,需要停机维护和数据迁移 ,多表的关联查询以及复杂的数据分析类型的复杂 sql 查询,性能欠佳。因为要 保证 ACID.
非关系型数据库:分布式,一般不保证遵循 ACID 原则的数据存储系统。键值对存储, 结构不固定。
优点:结构简单易扩展 ,高性能灵活的数据模型
缺点:只适合存储一些较为简单的数据 ,不适合复杂查询的数据 ,不适合持久存储海量数据
因此适合存储较为简单的数据。有一些不能够持久化数据,所以需要和关系型数据库结合。
二、mysql索引优缺点
索引优点
1.有助于加快数据检索,降低数据库I/O成本,这也是创建索引的最主要的原因。
2.通过创建唯一性索引,可以保证数据库表中每一行数据的唯一性
3.可以加速表和表之间的连接,实现数据的参考完整性方面特别有意义。
4.在使用分组和排序子句进行数据检索时,同样可以显著减少查询中分组和排序的时间,降低了 CPU 的消耗。
索引缺点
1.创建索引和维护索引需要耗费时间,当数据量增大的时候更加明显
2.索引需要占物理空间
3.表中的数据进行增加、删除和修改的时候,索引也要动态的维护,提高了CPU的消耗
三、给字段加索引最好怎么加?
建议创建索引的情况
1.根据查询要求建立索引:查询频率高、实时要求高的字段应该创建索引,如主键、外键、经常需要连接查询的字段、排序的字段、查询指定范围的字段。
2.数据量大的大表应该创建索引
不建议创建索引的情况
1.对数据表查询时很少引用到的、大量重复的字段不应该创建索引。
2.数据量非常小的数据表,索引能够改进其数据访问的效率十分有限,不必创建索引。
3.对于一个基本表不应该建立过多的索引,数据表进行增删改时,索引也随之变化。索引需要占用文件目录和存储空间,而且需要维护,过多会使系统负担加重。
四、什么情况下会导致索引失效?
1.组合索引最左前缀原则:在使用组合索引的列作为条件时,必须要出现最左侧列为条件,否则索引不生效
2.如果条件中有or,即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)
3.like查询以%开头,例如%张三、%张三%
4.字符串类型的字段,传入了int类型的参数时索引会失效,而int类型的字段传入字符串类型不会失效。
例如手机号码是字符串类型,传入了13057900876 也就是int类型的变量,就会导致索引失效。
根据mysql官网上解释,字符串’1’、’ 1 '、'1a’都能转换成int类型的1,也就是说可能会出现多个字符串对应一个int类型参数的情况,那么mysql怎么知道该把int类型的1转换成哪种字符串,用哪个索引快速查值?所以索引会失效。
五、为什么使用模糊匹配会使索引失效
索引其实就是排序,或者说排队更直观。
like ‘张三%’,实际你要找的是’张三XXX’,只要把所有’张三’开头的那部分内容返回即可,这部分是连续的,不需要全表扫描。
like ‘%张三’,实际你要找的是’XXX张三’,这部分在索引里是不连续的,如果要返回需要的结果,只能全表扫描。
六、回表查询和索引覆盖是什么
InnoDB聚集索引的叶子节点存储行记录,因此, InnoDB必须要有,且只有一个聚集索引:如果表定义了主键(一般ID自增),则主键就是聚集索引;
InnoDB普通索引的叶子节点存储主键值。
回表查询:根据普通索引的叶子节点上的主键值,重新定位主键索引树上的行记录。
例如:你给学生的学号加了唯一索引,但你现在执行这条sql:select name,sno from student where sno=123;因为name字段在学号索引树上不存在,需要拿着学号索引树上的主键值去主键索引树中找姓名,这就是一次回表查询。
索引覆盖就是⼀个SQL在执行时,可以利用索引来快速查找,并且此SQL所要查询的字段在当前索引对
应的字段中都包含了,那么就表示此SQL走完索引后不用回表了,所需要的字段都在当前索引的叶⼦节
点上存在,可以直接作为结果返回了。
七、联合索引的好处是什么
- 减少索引建立的开销。建了一个(a,b,c)的复合索引,那么实际等于建了(a),(a,b),(a,b,c)三个索引,因为每多一个索引,都会增加写操作的开销和磁盘空间的开销。对于大量数据的表,这可是不小的开销!
- 索引覆盖。同样的有复合索引(a,b,c),如果有如下的
select a,b,c from table where a=1 and b = 1
,**那么MySQL可以直接通过遍历索引取得数据,而无需回表。**在真正的实际应用中,索引覆盖是主要的提升性能的优化手段之一 - 减少扫描行数。有1000W条数据的表,有如下
select * from table where a = 1 and b =2 and c = 3
,假设假设每个条件可以筛选出10%的数据,如果只有单值索引,那么通过该索引能筛选出1000W*10%=100w 条数据,然后再回表从100w条数据中找到符合b=2 and c= 3的数据;如果是复合索引,可以通过索引筛选出1000w *10% *10% *10%=1w,然后再回表。
八、MySQL怎么判断走索引还是全表扫描
我们在查询有索引的字段时,有时候会发现居然没有走索引,而是走了全表扫描,因为MySQL发现走全表扫描会比走索引更快,因此选择了全表扫描。
例如你走了联合索引,找到七条符合条件的记录,然后要进行七次回表查询,mysql认为与其你先走了索引然后进行许多次的回表查询,不如直接全表扫描快,于是就虽然你用了索引但是还是全表扫描了。
小结:mysql会进行成本计算,用了索引的成本是多少,全表扫描的成本是多少,如果用了索引但是回表太多就去全表扫描
九、Explain语句结果中各个字段分别表示什么
比较重要的几个字段:
1.possible_keys: 代表可能用到的索引
2.key:实际上使用的索引
3.key_len:实际使用索引的长度
4.type所显示的是查询使用了哪种类型,type包含的类型包括如下图所示的几种:
从最好到最差依次是:
system > const > eq_ref > ref > range > index > all
1.system:表只有一行记录(等于系统表),这是const类型的特列,平时不会出现,这个也可以忽略不计
2.const:单表中最多只有一个匹配行(主键或唯一索引),在优化阶段即可读到数据
3.eq_ref:唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配。常见于主键或唯一索引扫描
4.ref:普通索引
5.range:范围查询,一般就是在你的where语句中出现between、< 、>、in等的查询,
6.index: 遍历索引树。这通常比ALL快,但是也没好到哪里去。
7.all:全表扫描,最差的情况下
5.Extra:十分重要的额外信息
6.Using index:表示相应的select操作中使用了覆盖索引(Covering Index)
7.Using where:表明使用了where过滤
十、Mysql慢查询该如何优化?
- 检查是否走了索引,如果没有则优化SQL利用索引。
- 检查所利用的索引,是否是最优索引。
- 检查所查字段是否都是必须的,是否查询了过多字段,查出了多余数据。
- 检查表中数据是否过多,是否应该进行分库分表了。
- 检查数据库实例所在机器的性能配置,是否太低,是否可以适当增加资源。
十一、左匹配,右匹配,inner join说一下区别
区别:
1.left以 left join 左侧的表为主表,左表中的记录都会出现在查询结果中,如果右表没有相匹配的记录,则以 null填充。
2.right 以 right join 右侧表为主表,记录都会出现在查询结果中,如果左表没有相匹配的记录,则以 null填充。
3.inner join 查找的数据是左右两张表共有的
什么是小表驱动大表 ?
小表驱动大表指的是用小的数据集驱动大得数据集。
1.当使用left join时,左表是驱动表,右表是被驱动表 ;
2.当使用right join时,右表时驱动表,左表是被驱动表 ;
3.当使用inner join时,mysql会选择数据量比较小的表作为驱动表,大表作为被驱动表 ;
例如:现有两个表A与B ,表A有200条数据,表B有20万条数据 :
小表驱动大表
for(200条)
for(20万条)
…
大表驱动小表
for(20万)
for(200条)
…
总结:
1.如果小的循环在外层,对于表连接来说就只连接200次 ;
2.如果大的循环在外层,则需要进行20万次表连接,从而浪费资源,增加消耗 ;
综上:
小表驱动大表的主要目的是通过减少表连接创建的次数,加快查询速度 。
十二、你对使用外键怎么看?
使用外键的原因
1.外键保证数据的完整性和一致性,不会得到孤立行。
2.可以获得良好的“级联删除,级联更新”行为,自动清理表
3.将数据完整性判断托付给了数据库完成,减少了程序的代码量
4.外键提供了一个非常重要的提示,说明在数据库中收集哪些统计信息最重要。
不使用外键的原因
1.数据库需要维护外键的内部管理。
2.外键等于把数据的一致性事务实现,全部交给数据库服务器完成,使数据库在每个CRUD操作上都额外工作,因为它必须检查外键一致性,这要消耗不少资源,如果进行大批量更新,这更是非常痛苦。
3.通过强制关系,外键指定了您必须添加/删除内容的顺序,例如如果学生关联了订单,必须先删除订单数据,在删除学生数据。
4.外键还会因为需要请求对其他表内部加锁而容易出现死锁情况。
例如:外键约束带来的开销还包括锁开销,比如向子表中添加一条数据,外键约束会让innodb检查对应的父表。这里会需要对父表进行加锁操作,来确保这条记录不会在事务完成之前被删除。这就带来了额外的锁开销。甚至死锁。
十三、说一下脏读、不可重复读以及幻读是什么
1、脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据。
2、不可重复读:事务 A 多次读取同一数据,事务 B 在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果不一致。
3、幻读:系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级,但是系统管理员B就在这个时候插入了一条具体分数的记录,当系统管理员A改结束后发现还有一条记录没有改过来,就好像发生了幻觉一样,这就叫幻读。
小结:不可重复读的和幻读很容易混淆,不可重复读侧重于修改,幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行,解决幻读需要锁表
注意:在innodb存储引擎下,引入mvvc之后已近解决了幻读问题。
十四、说说select … 这个查询语句,在mysql查询的过程
mysql分为server层与存储引擎层,server层包含连接器、分析器、优化器、执行器。
接下来以一条sql查询语句执行过程介绍各个部分功能。客户端执行一条sql:
1、连接器:连接到数据库,身份验证,权限管理
2、分析器:执行之前,MySQL肯定需要知道你要做啥,先进行词法分析,把关键字识别出来,再进行语法分析,看你的SQL语句语法是否有错。
3、优化器:通过分析器,我们知道了SQL需要做什么,但是直接根据SQL去获得结果可能会消耗很大性能,因此还得需要经过优化器对其进行优化。生成执行计划、选择索引等操作,选取最优执行方案
4、执行器,打开表调用存储引擎接口,逐行判断是否满足查询条件,满足放到结果集,最终返回给客户端;若用到索引,筛选行也会根据索引筛选。
十五、说说redo log和undo log 日志的过程
redo log作用:确保事务的持久性。防止在发生故障的时间点,尚有脏页未写入磁盘,在重启mysql服务的时候,根据redo log进行重做,从而达到事务的持久性这一特性。
内容:物理格式的日志,记录的是物理数据页面的修改的信息,其redo log是顺序写入redo log file的物理文件中去的。什么时候产生:事务开始之后就产生redo log,redo log的落盘并不是随着事务的提交才写入的,而是在事务的执行过程中,便开始写入redo log文件中。
undo log作用:如果因为某些原因导致事务失败或回滚了,可以借助该undo进行回滚。
内容:可以认为当delete一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当update一条记录时,它记录一条对应相反的update记录。当执行rollback时,就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
总结
作为JAVA开发程序员,与数据库打交道是必不可少的。MySQL作为当下热门的一款数据库,被广泛的应用到了企业实际开发中,同时在面试中也占了很大的比重,一定要熟练掌握。
以上是关于MySQL夺命连环15问,你能坚持到第几问?的主要内容,如果未能解决你的问题,请参考以下文章
ConcurrentHashMap源码夺命15问,你能坚持到第几问?