2023秋招大厂经典面试题及答案整理归纳（161-180）校招必看_《我想进大厂》面试题总结大全(上)-优快云博客

2、存储空间
MylSAJL可被压缩，存储空间较小。
InnoDB：需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引。
MvIS皿的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MylSAM体积庞大不小

3、事务处理
类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不支持外键、不提供事务支持。
InnoDB提供事务支持事务，外部键(foreign key)等高级数据库功能。 SELECT、UPDATE^ INSERT、Delete 操作
如果执行大量的SELECT, MylSAM是更好的选择。
如果你的数据执行大量的INSERT或UPDATE,岀于性能方面的考虑，应该使用 InnoDB 表。
DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。而则是重新建立表。在innodb上如果要清空保存有大量数据的表，最好使用truncate table这个命令。
AUTO_INCREMENT
MvISAJL可以和其他字段一起建立联合索引。引擎的自动増长列必须是索引，如果是组合索引，自动増长可以不是第一列，他可以根据前面几列进行排序后递増。
InnoDB： InnoDB中必须包含只有该字段的索引。引擎的自动増长列必须是索引，如果是组合索引也必须是组合索引的第一列。

4、表的具体行数
MylSAJL保存有表的总行数，如果select count (*) from table;会直接取岀该值。
InnoDB：没有保存表的总行数,如果使用select count (*) from table；就会遍历整个表，消耗相当大，但是在加了 where后，myisain和innodb处理的方式都一样。

5、全文索引
Myl SAJ】'土持FULLTEXT类型的全文索引。不支持中文。
InnoDB：不支持FULLTEXT类型的全文索引，但是innodb可以使用sphinx 插件支持全文索引，并且效果更好。

6、表锁差异
My I SAIL只支持表级锁,只支持表级锁，用户在操作myisain表时，select, update, delete, insert语句都会给表自动加锁。
InnoDB：支持事务和行级锁，是innodb的最大特色。行锁大幅度提高了多用户并发操作的新能。但是InnoDB的行锁也不是绝对的，如果在执行一个 SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表，例如 update table set nuirnl where name like aaa%”

162. 画出OSI和TCP/IP协议栈的对应关系.

OSI/RM共分为七层，TCP/IP分为四层。TCP/IP中的网络接口层相当于0SI 的物理层和数据槌路层，TCP的应用层相当于0SI的应用层、表示层和会话层。其余层次基本对应。见图，其中外围深颜色的是0SI层次，内部白颜色的是TCP层次。

163. 简述停止-等待协议（ARQ）的工作原理？

全双工通信的双方既是发送方也是接收方。为了讨论方便，仅考虑A发送数据而B接收数据并发送确认。A叫发送方，B叫接收方。“停止等待”就是每发送完一个分组就停止发送，等特对方的确认。在收到确认后再发送下一个分组。

1、无差错情况
A发送分组Ml,发送完后就暂停发送，等待B的确认。B收到Ml后就向A发送确认。A在收到对Ml的确认后，就继续发送下一个分组M2。同样，在收到B对M2的确认后，再继续发送下一个分组。

2、岀现差错
A只要超过一段时间后仍没有收到确认，就认为刚发送的分组丢失，因而重侍前面发送过的分组。实现这个功能应该保证：
—、A在发送完一个分组后，必须暂时保留已发送的分组的副本。只有在收到相应的确认后才能清除暂时保留的分组副本。
二、分组和确认分组都必须进行编号。
三、超时计时器设置的重传时间应当比数据在分组侍a输的平均往返时间更长一些。

3、源丢失和确认迟到
假设当B发送的对M2确认丢失后，A在设定的超时重传时间内没有收到M2 的确认，但并不知道是自己发送的分组岀错、丢失，或者B发送的确认丢失。因此A在超时计时器到期后就要重传分组M2。B在收到M2后应釆取的两个动作：
—、丢弃这个重复的分组M2。
二、向B发送确认。
这种可靠传输协议称为自动重传请求ARQ (Automatic Repeat reQuest), 可以在不可靠的传输网络上实现可靠的通信。

164. redis的持久化有哪几种方式？不同的持久化机制都有什么优缺点？

redis持久化的两种方式
RDB： RDB持久化机制，是对redis中的数据执行周期性的持久化。
AOF： AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集。
通过RDB或AOF,都可以将redis内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云等云服务。
如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中,然后重新启动redis, redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务。
如果同时使用RDB和BOF两种持久化机制，那么在redis重启的时候，会使用AOF来重新构建数据，因为BOF中的数据更加完整。

RDB优缺点
RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说Amazon的S3云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份 redis中的数据。
RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork —个子进程，让子进程执行磁盘10操作来进行RDB持久化即可。
相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis 进程，更加快速。
如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。 —般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次, 这个时候就得接受一旦redis进程宕机，那么会丟失最近5分钟的敬据。 RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。 AOF优缺点
AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易仮损，即使文件尾部破损，也很容易修复。

A0F日志文件即使过大的时候，岀现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建岀一份需要恢复数据的最小日志岀来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常