1、锁级别为表锁,表锁优点是开销小,加锁快;缺点是锁粒度大,发生锁冲动概率较高,容纳并发能力低,这个引擎适合查询为主的业务。
2、此引擎不支持事务,也不支持外键。
3、INSERT和UPDATE操作需要锁定整个表;
3、它存储表的行数,于是SELECT COUNT(*) FROM TABLE时只需要直接读取已经保存好的值而不需要进行全表扫描。
(三) 适用场景
MyISAM适合: (1)做很多count 的计算;(2)插入不频繁,查询非常频繁;(3)没有事务。
InnoDB适合: (1)可靠性要求比较高,或者要求事务;(2)表更新和查询都相当的频繁,并且表锁定的机会比较大的情况。
三: 如何选择Mysql的存储引擎
根据系统的业务要求选择,首先要了解索引的特点
InnoDB: 如果对数据的完整性要求比较高,且除了插入和查询外,还存在着许多更新和删除操作的,适用于选择InnoDB,InnoDB也是Mysql现在默认的存储引擎。
MyISAM: 以只读或者插入操作为主,很少的更新和删除操作的,并且对数据完整性要求不高的可以选择。
四: 数据库语句的执行顺序
(一): 执行顺序
from -> on -> join -> where -> group by -> having -> count(聚合函数) -> select -> distinct -> order by -> limit
(二): 执行步骤解释:
(1)、from: 表示数据的来源
(2)、on: 表示数据的关联表,执行完后生成一个临时表t1,提供给下一步的操作使用
(3)、join: 将join表的数据补充到on执行完成的临时表t1中,如: left join则将坐标剩余的数据添加到临时表t1中,如果join超过3个,则重复on…join之间的步骤。
(4)、where: 根据携带的条件,从临时表中筛选出符合条件的数据,并生成临时表t2。
(5)、groub by: 根据携带的条件,将临时表t2进行相应的数据分组,并形成临时表t3,如果语句包含了group by则它后面的字段必须出现在select中或者出现在聚合函数中,否则会报SQL语法错误。
(6)、having: 筛选分组后临时表t3的数据,得到临时表t4。
(7)、count等聚合函数: 对临时表进行指定字段的聚合函数操作,形成临时表t5。
(8)、select: 从临时表筛选出需要返回的数据,形成临时表t6。
(9)、distinct: 对临时表t6进行指定的去重筛选,形成临时表t7。
(10)、order by: 对临时表t7排序,形成临时表t8。
(11)、limit: 筛选返回的数据条数
想要了解更多的执行过程的问题,可以查看之前专门解析执行过程的文章: 你真的懂使用Group by?
五: Mysql和PostGreSQL有什么区别?
回答思路:
面试官询问这个问题,原因可能是你在自己的简历中有描述使用到两种不同的数据,主要考察两个方面。
一个是考察你在工作中是否善于思考,一般数据库的选型都是公司的架构师或者组长选择,你可能只是一名组员,只需要负责使用即可,但是,如果你能够主动去思考为什么会选择使用这个数据库而不是使用其他数据库,了解两者的一些差别,这个会很给面试官添加印象分,证明你在平常的工作中是善于去思考的。
第二个考察的方面,是看你是否能够结合项目或者公司现在有的业务去讲解使用当前数据库的一些利弊,这同样也是一个加分项,毕竟技术的选型最后还是要考虑业务的支撑,因此,这个问题主要从这两方面回答会有很不错的效果。
第一方面:
1、Mysql中text类型有不同的限制(既:small text middle text…),但是Pg没有这种限制。
2、MySQL 里需要 utf8mb4 才能显示 emoji 的坑, Pg 就没这个坑。
3、MySQL 不支持 OVER 子句, 而 Pg 支持. OVER 子句能简单的解决 “每组取 top 5” 的这类问题。
4、pg支持更多的数据类型如:jsonb array等,对地理信息处理扩展更好的支持,有更多的数据源。
5、在高并发读写,负载逼近极限下,PG的性能指标仍可以维持双曲线甚至对数曲线,到顶峰之后不再下降,而 MySQL 明显出现一个波峰后下滑
第二方面:
可以结合项目的一些业务场景来回答体现使用这种数据库的优势。如使用PostgreSQL,回答如下。
因为这个项目的技术选型是由我们公司架构师进行选择的,但是,我也通过项目和公司的业务了解到一些选择PG数据库的好处,我们的公司主要项目是公安的相关系统,系统中涉及到很多地理位置信息数据的处理,PG数据库对地理信息的存储和拓展都有很好的支持,这也是我们项目中选择PG数据库的一个原因等等。
六: 事务的隔离级别和存在的问题
(一): Read Uncommited(读未提交)
1、定义: 可以读取到其他没有提交的事务的内容。
2、并发情况下存在的问题: 脏读,不可重复读,幻读
(二): Read Committed(读已提交)
1、定义: 可以读取到其他提交的事务的内容。
2、并发情况下存在的问题: 不可重复读,幻读
(三): Repeatbale Read(可重复读)
1、定义: 同一个事务下可以重复读取,数据都一样。
2、并发情况下存在的问题: 幻读(采用多版本并发控制(MVCC)机制解决幻读问题。)
(四): serialized(串行化)
1、可读,不可写。像java中的锁,写数据必须等待另一个事务结束。
2、不存在问题
七: 事务并发情况下出现的问题和解决方案
(一): 出现的问题:
1、更新丢失: 并发事务时,可能出现多个事务同时更新同一条记录,导致前一个事务更新的被后面事务的更新覆盖。
2、脏读: 一个事务读取到另一个事务没有提交的数据
3、不可重复读: 在同一个事务中,前后读取的相同的条件下的数据不一样(在并发情况下另外一个事务对数据进行了修改)
4、幻读: 同一个事务下,前后读取的数据不一样(在并发情况下,另外的事务对数据进行了删除或者增加的操作)
(二): 解决方案:
1、更新丢失更新问题可以通过应用层来解决,如加锁。
2、脏读、不可重复读、幻读通过数据库提供的隔离机制进行处理,实现隔离机制的方法如下: 加读写锁,一致性快照读即MVCC。
八: 数据库范式的理解
1、第一范式: 每个列都不能再拆分
2、第二范式: 在第一范式的基础上,非主键列完全依赖于主键,而不能依赖于主键的一部分。
举例:
如关系模型(职工号,姓名,职称,项目号,项目名称)中,职工号->(依赖)姓名,职工号->职称,而项目号->项目名称(项目名称依赖于项目号,但是项目号并不是这个关系模型中的主键)。显然依赖关系不满足第二范式,常用的解决办法是拆分表格,比如拆分为职工信息表和项目信息表。
3、第三范式: 在第二范式的基础上,非主键列只依赖于主键,不依赖于其他非主键(不存在传递依赖)
举例:
如:Student表(学号,姓名,年龄,性别,所在院校,院校地址,院校电话)这样一个表结构,就存在上述关系。 学号–> 所在院校 --> (院校地址,院校电话)。我们应该拆开来,如下:
(学号,姓名,年龄,性别,所在院校)–(所在院校,院校地址,院校电话)
总结:
第一范式:具有原子性
复习的面试资料
这些面试全部出自大厂面试真题和面试合集当中,小编已经为大家整理完毕(PDF版)
- 第一部分:Java基础-中级-高级
- 第二部分:开源框架(SSM:Spring+SpringMVC+MyBatis)
- 第三部分:性能调优(JVM+MySQL+Tomcat)
- 第四部分:分布式(限流:ZK+Nginx;缓存:Redis+MongoDB+Memcached;通讯:MQ+kafka)
- 第五部分:微服务(SpringBoot+SpringCloud+Dubbo)
- 第六部分:其他:并发编程+设计模式+数据结构与算法+网络
进阶学习笔记pdf
- Java架构进阶之架构筑基篇(Java基础+并发编程+JVM+MySQL+Tomcat+网络+数据结构与算法)
- Java架构进阶之开源框架篇(设计模式+Spring+SpringMVC+MyBatis)
- Java架构进阶之分布式架构篇 (限流(ZK/Nginx)+缓存(Redis/MongoDB/Memcached)+通讯(MQ/kafka))
- Java架构进阶之微服务架构篇(RPC+SpringBoot+SpringCloud+Dubbo+K8s)
)*
[外链图片转存中…(img-PYvevaHh-1714529201364)]
[外链图片转存中…(img-EJPkhJ4z-1714529201365)]
[外链图片转存中…(img-cqjzvkPl-1714529201365)]
- Java架构进阶之分布式架构篇 (限流(ZK/Nginx)+缓存(Redis/MongoDB/Memcached)+通讯(MQ/kafka))
[外链图片转存中…(img-U4PDMzak-1714529201365)]
[外链图片转存中…(img-OihO5lPW-1714529201366)]
[外链图片转存中…(img-CbfsogWT-1714529201366)]
- Java架构进阶之微服务架构篇(RPC+SpringBoot+SpringCloud+Dubbo+K8s)
[外链图片转存中…(img-O7glHN9w-1714529201366)]
[外链图片转存中…(img-KC1MWfjm-1714529201367)]