常见的面试问题

李昂君

发布于 2021-12-24 18:16:51

7620

文章被收录于专栏：李昂君李昂君

阅读量: 60

1、Mysql链表概述

　　因为表与表之间有关系，而且查询时需要两张表的某些数据。

链表的前提是：表与表之间必须设置主外键吗？

　　不是的，其实表与表之间不需要设置主外键关系，用数据库语句就可以实现链表查询，删除，修改，增加等操作。

为什么要设置主外键呢？

　　通常我们看到表与表之间有关系，常常设置主外键。为什么？其实这样做是为了规范！假设一个不了解你表结构的人，都能够任意的修改你的外键。那这个表就不严谨了。

我们到底设不设主外键呢？这就要分情况：

1、如果表结构简单，少量的表。逻辑不复杂。那么这个就不需要设置主外键了。特别对于数据库语句不熟悉的人，就方便多了。

2、如果表结构复杂，有大量的表，逻辑复杂的。那么自己不可能记住所有主外键之间的关系，那么就需要设置主外键。

链表查询又分为：左联表，右链表。等。

链表不仅可以进行查询，还可以链表查询，链表增加，链表删除，链表修改。

2、Mysql索引的优缺点

优点：

索引大大减小了服务器需要扫描的数据量
索引可以帮助服务器避免排序和临时表
索引可以将随机IO变成顺序IO
索引对于InnoDB（对索引支持行级锁）非常重要，因为它可以让查询锁更少的元组。在MySQL5.1和更新的版本中，InnoDB可以在服务器端过滤掉行后就释放锁，但在早期的MySQL版本中，InnoDB直到事务提交时才会解锁。对不需要的元组的加锁，会增加锁的开销，降低并发性。 InnoDB仅对需要访问的元组加锁，而索引能够减少InnoDB访问的元组数。但是只有在存储引擎层过滤掉那些不需要的数据才能达到这种目的。一旦索引不允许InnoDB那样做（即索引达不到过滤的目的），MySQL服务器只能对InnoDB返回的数据进行WHERE操作，此时，已经无法避免对那些元组加锁了。如果查询不能使用索引，MySQL会进行全表扫描，并锁住每一个元组，不管是否真正需要。
- 关于InnoDB、索引和锁：InnoDB在二级索引上使用共享锁（读锁），但访问主键索引需要排他锁（写锁）

缺点：

虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存索引文件。
建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。
如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。
对于非常小的表，大部分情况下简单的全表扫描更高效；

索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。

因此应该只为最经常查询和最经常排序的数据列建立索引。

MySQL里同一个数据表里的索引总数限制为16个。

索引存储类型有哪些？

B-Tree
Hash

索引的使用方式有哪些？

普通索引
唯一索引
主键索引
联合索引
外键索引
全文索引

3、什么是读锁、写锁、读写锁

读写锁有四种操作：

读上锁
读解锁
写上锁
写解锁

写锁最多有一个，读锁可以有多个(最大个数据说和CPU个数有关) 写锁的优先级高于读锁，这是因为为了防止读锁过多，写锁一直堵塞的情况发生

锁，这种东西其实就是为了保护数据不被并发给搞炸了，然而，当真正拥有极大量数据并发的时候，锁其实已经满足不了一些场景了，因为会造成大量的资源请求的竞争，只有一个线程抢到资源，其他大量的请求都等着，这样无疑对其他请求来说是一个很慢的响应。可以用其他的方式来解决锁的问题，比如事后的补偿机制。至于该不该用锁，其实也应该根据现场的实际情况来抉择。如果锁的速度比其他方式的响应速度更快或者差不多，那其实也没必要用其他方式来做，还是得看实际的情况。

4、Tcp三次握手流程

关于TCP协议三次握手的问题，在面试中是最为常见的知识点之一，得到了很多面试官的青睐，如果这个知识点没有掌握好，面试官要是问得深入一点，求职者往往会不知所措。

为什么建立连接需要三次握手？

首先非常明确的是两次握手是最基本的。第一次握手，客户端发了个连接请求消息到服务端，服务端收到信息后知道自己与客户端是可以连接成功的，但此时客户端并不知道服务端是否已经接收到了它的请求，所以服务端接收到消息后的应答，客户端得到服务端的反馈后，才确定自己与服务端是可以连接上的，这就是第二次握手。

客户端只有确定了自己能与服务端连接上才能开始发数据。所以两次握手肯定是最基本的。

看到这里，你或许会问，那么为什么需要第三次握手呢？我们来看一下，假设一下如果没有第三次握手，而是两次握手后我们就认为连接成功了，那么会发生什么？第三次握手是为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误。

譬如发起请求遇到类似这样的情况：客户端发出去的第一个连接请求由于某些原因在网络节点中滞留了导致延迟，直到连接释放的某个时间点才到达服务端，这是一个早已失效的报文，但是此时服务端仍然认为这是客户端的建立连接请求第一次握手，于是服务端回应了客户端，第二次握手。

TCP三次握手流程

如果只有两次握手，那么到这里，连接就建立了，但是此时客户端并没有任何数据要发送，而服务端还在傻傻的等候佳音，造成很大的资源浪费。所以需要第三次握手，只有客户端再次回应一下，就可以避免这种情况。

百度百科介绍：点我进入

5、常见的网络状态码有哪些，能介绍下呢？

状态码的职责

状态码适当客户端向服务器端发出请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是发生了错误。

它是用以表示网页服务器HTTP响应状态的3位数字代码。状态码的第一个数字代表了响应的五种状态之一。

一些常见HTTP状态码为：

200 – 服务器成功返回网页
404 – 请求的网页不存在
503 – 服务不可用

1XX（临时响应）

表示临时响应并需要请求者继续执行操作的状态代码。指定客户端应相应的某些动作，代表请求已被接受，需要继续处理。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送 1xx 响应。

状态码	含义	说明
100	继续	请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
101	切换协议	请求者已要求服务器切换协议，服务器已确认并准备切换。
102	继续执行	由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。

2XX（成功）

表示成功处理了请求的状态代码。代表请求已成功被服务器接收、理解、并接受。这系列中最常见的有200、201状态码。

状态码	含义	说明
200	成功	服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。
201	已创建	请求成功并且服务器创建了新的资源。
202	已接受	服务器已接受请求，但尚未处理。
203	非授权信息	服务器已成功处理了请求，但返回的信息可能来自另一来源。
204	无内容	服务器成功处理了请求，但没有返回任何内容。
205	重置内容	服务器成功处理了请求，但没有返回任何内容。
206	部分内容	服务器成功处理了部分 GET 请求。

3XX（重定向）

表示要完成请求，需要进一步操作。通常，这些状态代码用来重定向。代表需要客户端采取进一步的操作才能完成请求，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。这系列中最常见的有301、302状态码。

状态码	含义	说明
300	多种选择	针对请求，服务器可执行多种操作。服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301	永久移动	请求的网页已永久移动到新位置。服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302	临时移动	服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303	查看其他位置	请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304	未修改	自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。
305	使用代理	请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。
307	临时重定向	服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

4XX（请求错误）

这些状态代码表示请求可能出错，妨碍了服务器的处理。表示请求错误。代表了客户端看起来可能发生了错误，妨碍了服务器的处理。常见有：401、404状态码。

状态码	含义	说明
400	错误请求	服务器不理解请求的语法。
401	未授权	请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。
403	禁止	服务器拒绝请求。
404	未找到	服务器找不到请求的网页。
405	方法禁用	禁用请求中指定的方法。
406	不接受	无法使用请求的内容特性响应请求的网页。
407	需要代理授权	此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408	请求超时	服务器等候请求时发生超时。
409	冲突	服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。
410	已删除	如果请求的资源已永久删除，服务器就会返回此响应。
411	需要有效长度	服务器不接受不含有效内容长度标头字段的请求。
412	未满足前提条件	服务器未满足请求者在请求中设置的其中一个前提条件。
413	请求实体过大	服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414	请求的 URI 过长	请求的 URI（通常为网址）过长，服务器无法处理。
415	不支持的媒体类型	请求的格式不受请求页面的支持。
416	请求范围不符合要求	如果页面无法提供请求的范围，则服务器会返回此状态代码。
417	未满足期望值	服务器未满足”期望”请求标头字段的要求。

5XX（服务器错误）

这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。常见有500、503状态码。

状态码	含义	说明
500	服务器内部错误	服务器遇到错误，无法完成请求。
501	尚未实施	服务器不具备完成请求的功能。例如，服务器无法识别请求方法时可能会返回此代码。
502	错误网关	服务器作为网关或代理，从上游服务器收到无效响应。
503	服务不可用	服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态。
504	网关超时	服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505	HTTP 版本不受支持	服务器不支持请求中所用的 HTTP 协议版本。

6、Redis的问题

存储方式有那些类型

字符(String)
哈希(Hash)
列表(List)
集合(Set)

Hash的原理

Redis 中的 Hash和 Java的 HashMap 更加相似，都是数组+链表的结构，当发生 hash 碰撞时将会把元素追加到链表上。值得注意的是在 Redis 的 Hash 中 value 只能是字符串。

内部原理

看完基本介绍之后,我们先来了解下 hash 的内部结构，第一维是数组，第二维是链表。组成一个 hashtable。

hash编码类型

ziplist（压缩列表）

当哈希类型的元素个数小于hash-max-ziplist-entries配置（默认512个），同时所有值都小于hash-maxziplist-value配置（默认为64字节），Redis会使用ziplist做为哈希的内部实现。Ziplist可以使用更加紧凑的结构来实现多个元素的连续存储，所以在节省内存方面更加优秀。