总结
我个人认为，如果你想靠着背面试题来获得心仪的offer，用癞蛤蟆想吃天鹅肉形容完全不过分。想必大家能感受到面试越来越难，想找到心仪的工作也是越来越难，高薪工作羡慕不来，却又对自己目前的薪资不太满意，工作几年甚至连一个应届生的薪资都比不上，终究是错付了，错付了自己没有去提升技术。
这些面试题分享给大家的目的，其实是希望大家通过大厂面试题分析自己的技术栈，给自己梳理一个更加明确的学习方向，当你准备好去面试大厂，你心里有底，大概知道面试官会问多广，多深，避免面试的时候一问三不知。
大家可以把Java基础，JVM，并发编程，MySQL，Redis，Spring，Spring cloud等等做一个知识总结以及延伸，再去进行操作，不然光记是学不会的，这里我也提供一些脑图分享给大家：
希望你看完这篇文章后，不要犹豫，抓紧学习，复习知识，准备在明年的金三银四拿到心仪的offer，加油，打工人！
-
非授权用户对数据库的恶意存取和破坏
-
数据库中重要或敏感的数据被泄露
-
安全环境的脆弱性
2.数据库安全性控制
- 用户身份识别
常用的用户身份鉴别方法有一下几种：
-
静态口令鉴别
-
动态口令鉴别
-
生物特征鉴别
-
智能卡鉴别
-
存取控制
数据库安全最重要的一点就是确保只授权给有资格的用户访问数据库的权限，同时令所有未被授权的人员无法接近数据，这主要通过数据库系统存取控制机制实现。
存取控制机制主要包括定义用户权限和合法权限检查两部分。
定义用户权限和合法权限检查机制一起组成了数据库管理系统的存取控制子系统。
C2级的数据库管理系统支持自主存取控制（DAC），B1级的数据库管理系统支持强制存取控制（MAC）。
- 自主存取控制
用户对于不同的数据库对象有不同的存取权限，不同的用户对同一对象也有不同的权限，而且用户还可以将其拥有的存取权限转授给其他用户。因此自主存取控制非常灵活。
- 强制存取控制
每一个数据库对象被标以一定的密级，每一个用户也被授予某一个级别的许可证。对于任意一个对象，只有合法许可证的用户才可以存取。强制存取控制因此相对严格。
- 视图机制
可以为不同的用户定义不同的视图，把数据对象限制在一定的范围内。也就是说，通过视图机制把要保密的数据对无权存取的用户隐藏起来，从而自动对数据提供一定程度的安全保护。
- 审计
审计功能把用户对数据库的所有操作自动记录下来放入审计日志中，审计员可以利用审计日志监控数据库中的各种行为，重现导致数据库现有状况的一系列事件，找出非法存取数据的人，时间和内容等。
- 审计事件
-
服务器事件
-
系统权限
-
语句事件
-
模式对象事件
- 数据加密
加密的思想是根据一定的算法将原始数据----明文变换为不可以直接识别的格式----密文，从而使得不知道解密算法的人无法知道数据的内容。
数据加密主要包括存储加密和传输加密。
数据库的完整性是指数据的正确性和相容性。
为维护数据库的完整性，数据库管理系统必须能够实现如下功能：
-
提供定义完整性约束条件的机制
-
提供完整性检查的方法
-
进行违约处理
1.实体完整性
- 定义实体完整性
关系模型的实体完整性在create table中用primary key定义。对单属性构成的码有两种说明方法，一种是定义为列级约束条件，另一种是定义为表级约束条件。对多个属性构成的码只有一种说明方法，即定义表级约束条件。
-
实体完整性检查和违约处理
-
检查主码值是否唯一，如果不唯一则拒绝插入或修改。
-
检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改。
2.参照完整性
- 定义参照完整性
关系模型的参照完整性在create table中用foreign key短语定义哪些列为外码，用references短语指明这些外码参照哪些表的主码。
- 参照完整性检查和违约处理
| 被参照表 | 参照表 | 违约处理 |
| :-: | :-: | :-: |
| 可能破坏参照完整性 | 插入元组 | 拒绝 |
| 可能破坏参照完整性 | 修改外码值 | 拒绝 |
| 删除元组 | 可能破坏参照完整性 | 拒绝/级联删除/设置为空值 |
| 修改外码值 | 可能破坏参照完整性 | 拒绝/级联删除/设置为空值 |
当可能破坏参照完整性，系统可能采用以下策略加以处理：
- 拒绝执行
不允许该操作执行。该策略一般设置为默认策略。
- 级联操作
当删除或修改被参照表的一个元组导致与参照表的不一致时，删除或修改参照表中的所有导致不一致的元组。
- 设置为空值
当删除或修改被参照表的一个元组时造成不一致，则将参照表中的所有造成不一致的元组的对应属性设置为空值。
3.用户定义完整性
-
属性上的约束条件
-
属性上约束条件定义
在create table中定义属性的同时，可以根据应用要求定义属性上的约束条件，即属性值限制。包括：
-
列值非空（not null）
-
列值唯一（unique）
-
检查列值是否满足一个条件表达式（check语句）
- 属性上约束条件的检查和违约处理
当往表中插入元组或修改属性的值时，关系数据库管理系统将检查属性上的约束条件是否被满足，如果不满足则操作被拒绝执行。
-
元组上的约束条件
-
元组上约束条件的定义
-
元组上约束条件的检查和违约处理
- 数据库设计的基本步骤
-
需求分析阶段
-
概念结构设计阶段
-
逻辑结构设计阶段
-
物理结构设计阶段
-
数据库实施阶段
-
数据库运行和维护阶段
- 数据字典
是关于数据库中数据描述，即元数据，而不是数据本身。数据字典是在需求分析阶段建立，在数据库设计过程中不断修改，充实，完善的。
组成部分：
-
数据项：数据项是不可在分的数据单位。
-
数据结构：数据结构反映数据之间的组合关系。
-
数据流：数据流是数据结构在系统内传输的路径。
-
数据存储：数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。
-
处理过程：处理过程的具体处理逻辑一般用判定表或判定树来描述。
-
E-R图像关系模型的转换原则
-
一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
-
一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
-
一个m:n联系转换为一个关系模式。
-
三个或三个以上实体间的一个多元联系可以转换为一个关系模式。
-
具有相同码的关系模式可合并。
- 嵌入式sql语句与主语言之间的通信
-
向主语言传递SQL语句的执行状态信息，使主语言能够根据此信息控制程序流程，主要用SQL通信区（SQLCA）实现。
-
主语言向SQL语句提供参数，主要用主变量实现。
-
将SQL语句查询数据库的结果交主语言处理，主要用主变量和游标实现。
-
建立和关闭数据库连接。
- 使用游标的SQL语句
-
说明游标
-
打开游标
-
推进游标指针并取当前记录
-
关闭游标
1.查询处理
查询处理的步骤：
- 查询分析
首先对查询语句进行扫描，词法分析和语法分析。进行语法检查和语法分析，即判断查询语句是否符合SQL语法规则，如果没有语法错误就转入下步处理，否则便报告语句中出现的语法错误。
- 查询检查
对合法的查询语句进行语义检查，即根据数据字典中有关的模式定义检查语句中的数据库对象，如关系名，属性名是否存在和有效。如果是对视图的操作，则要用视图消解方法把视图的操作转换成对基本表的操作。还要根据数据字典中的用户权限和完整性约束定义对用户的存取权限进行检查。如果该用户没有相应的访问权限或违反了完整性约束，就拒绝执行该查询。
- 查询优化
查询优化是选择一个高效执行的查询处理策略。查询优化有多种方法。按优化的层次一般可将查询优化分为“代数优化”和“物理优化”。
-
代数优化（逻辑优化）：是指关系代数表达式的优化，即按照一定的规则，通过对关系代数表达式进行等价变换，改变代数表达式中操作的次序和组合，使查询执行更高效。
-
物理优化（非代数优化）：是指存取路径和底层操作算法的选择。选择的依据可以是基于规则的，也可以的基于代价的，还可以是基于语义的。
- 查询执行
依据优化器得到的执行策略生成查询执行计划，有代码锁存器生成执行整个查询计划的代码，然后加以执行，回送查询结果。
2.常见的启发式原则
- 查询数的启发式优化
-
选择运算应尽可能先做。
-
把投影运算和选择运算同时进行。
-
把投影同其前或后的双目运算结合起来。
-
把某些选择同在他前面要执行的笛卡尔积结合起来成为一个连接运算。
-
找出公共子表达式。
1.事务
事务：事务是用户定义的一个数据库操作序列，这些操作要么全不做，要么全做，是一个不可分割的工作单位。通常以begin transaction开始，以commit或rollback结束。
commit：表示提交，即提交事务的所有操作。具体来说就是将事务中所有对数据库的更新写回到磁盘上的物理数据库中去，事务正常结束。
rollback：表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态。这里的操作指对数据库的更新操作。
2.事务的ACID特性
- 原子性（Atomicity）
事务被视为不可分割的最小单位，事务所有的操作要么全部提交成功，要么全部失败回滚。
- 一致性（Consistency）
数据库在事务执行前后都保持一致性状态。在一致性状态下，所有事务对同一个数据的读取结果都是相同的。
- 隔离性（Isolation）
一个事务的执行不能被其他事务干扰。即一个事务的内部操作及使用的数据对其他并发事务是隔离的。接下来的其它操作或故障不应该对其执行结果有任何影响。
- 持久性（Durability）
一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。
3.故障的种类
-
事务内部故障
-
系统故障
-
介质故障
-
计算机病毒
4.恢复的实现技术
-
动态海量存储
-
动态增量存储
-
静态海量存储
-
静态增量存储
静态转储：是在系统中无运行事务时进行的转储操作。
动态转储：是指转储期间允许对数据库进行存取或修改。
海量存储：是指每次转储全部数据库。
增量存储：是指每次只转储上一次转储后更新过的数据。
5.登记日志文件
-
日志文件中需要登记的内容包括
-
各个事务的开始标记。
-
各个事务的结束标记。
-
各个事务的所有更新操作。
-
每个日志记录的内容主要包括
-
事务标识
-
操作的类型
-
操作对象
-
更新前数据的旧值
-
更新后数据的新值
-
登记日志文件时必须遵循两条原则
-
登记的次序严格按并发事务执行的时间次序。
-
必须先写日志文件，后写数据库。
6.恢复策略
- 检查点记录
检查点记录的内容包括：
-
建立检查点时刻所有正在执行的事务清单。
-
这些事务最近一个事务记录的地址。
动态维护日志文件的方法是，周期性地执行建立检查点，保存数据库状态的操作。
使用检查点方法可以改善恢复效率。
- 数据库镜像
1.并发一致性问题
- 丢失修改
两个事务T1和T2读入同一数据并修改。T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失。
- 读脏数据
读脏数据是指事务T1修改某一数数据并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被撤销，这时被T1修改的数据恢复原值，T2读到的数据就与数据库中的数据不一致。
- 不可重复读
指事务T1读取数据后，事务T2执行更新操作，使T1无法再现前一次读取结果。具体分三种情况：
-
事务T1读取某一数据后，事务T2对其进行了修改，当事务T1再次读该数据时，得到与前一次不同的值。
-
事务T1按一定条件从数据库中读取某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录神秘消失了。
-
事务T1按一定条件从数据库中读取某些数据记录后，事务T2插入一些记录，当T1再次按相同条件读取数据时，发现多了一些记录。
后面两种不可重复读有时也称为幻影现象。
产生并发不一致性问题的主要原因是并发操作破坏了事务的隔离性。并发控制机制就是要用正确的方式调度并发操作，使一个用户书屋的执行不受其他事务的干扰，从而避免造成数据的不一致性。
并发控制的主要技术：
封锁，时间戳，乐观控制法，多版本并发控制等。
2.封锁
- 封锁粒度
封锁粒度：封锁对象的大小。封锁粒度与系统的并发度和并发控制的开销密切相关。直观来看，封锁的粒度越大，数据库所能封锁的数据单元就越少，并发度就越小，系统开销也越小，反之，封锁的粒度越小，并发度较高，但系统开销也就越大。
-
封锁类型
-
读写锁
- 排他锁（写锁）：简称为X锁。
若事务T对数据对象A加了X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁为止。
- 共享锁（读锁）：简称为S锁。
若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁为止。
- 意向锁
- IS锁（意向共享锁）
如果对一个数据对象加IS锁，表示它的后裔结点拟（意向）加S锁。
- IX锁（意向排他锁）
如果对一个数据对象加IX锁，表示它的后裔结点拟（意向）加X锁。
- SIX锁（共享意向排他锁）
如果对一个数据对象加SIX锁，表示对它加S锁，再加IX锁，即SIX=S+IX。
-
封锁协议
-
三级封锁协议
-
一级封锁协议
事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（commit）和非正常结束（rollback）。
- 二级封锁协议
在一级封锁协议基础上增加事务T在读取数据R之前必须对其加S锁，读完后即可释放S锁。
结语
小编也是很有感触，如果一直都是在中小公司，没有接触过大型的互联网架构设计的话，只靠自己看书去提升可能一辈子都很难达到高级架构师的技术和认知高度。向厉害的人去学习是最有效减少时间摸索、精力浪费的方式。
我们选择的这个行业就一直要持续的学习，又很吃青春饭。
虽然大家可能经常见到说程序员年薪几十万，但这样的人毕竟不是大部份，要么是有名校光环，要么是在阿里华为这样的大企业。年龄一大，更有可能被裁。
送给每一位想学习Java小伙伴，用来提升自己。
本文到这里就结束了，喜欢的朋友可以帮忙点赞和评论一下，感谢支持！
IX。
-
封锁协议
-
三级封锁协议
-
一级封锁协议
事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（commit）和非正常结束（rollback）。
- 二级封锁协议
在一级封锁协议基础上增加事务T在读取数据R之前必须对其加S锁，读完后即可释放S锁。
结语
小编也是很有感触，如果一直都是在中小公司，没有接触过大型的互联网架构设计的话，只靠自己看书去提升可能一辈子都很难达到高级架构师的技术和认知高度。向厉害的人去学习是最有效减少时间摸索、精力浪费的方式。
我们选择的这个行业就一直要持续的学习，又很吃青春饭。
虽然大家可能经常见到说程序员年薪几十万，但这样的人毕竟不是大部份，要么是有名校光环，要么是在阿里华为这样的大企业。年龄一大，更有可能被裁。
送给每一位想学习Java小伙伴，用来提升自己。
[外链图片转存中…(img-wYU71Gbu-1715248993290)]
本文到这里就结束了，喜欢的朋友可以帮忙点赞和评论一下，感谢支持！
扫一扫
1861
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
