那我也来一波最近热腾腾的面试题?

其实最近还在职,不过处于辞职交接状态,就挂了简历,但是没投。看到有邀约的,就和自己高度匹配的几家面试了,陆续拿到了几个offer。回忆一波面试题。按照类别来分了,因为有些也忘了是那次面试的,列的都是印象比较深刻的题目,有些忘了。如果回答错了,欢迎纠正补充。

mysql

1.谈谈你在写sql语句需要注意有哪些点?

答:

  1. select * 问题,客户端需要什么,就给什么,不要给多余的字段,这种情况可能还会导致本来可以走覆盖索引的语句不能走覆盖索引。
  2. 不要在查询语句字段上做函数运算,这样会让索引失效。
  3. 一定要避免mysql自动类型转换,比如 where ‘9’ =9。
  4. 能不设置允许 null 的字段尽量不要设置,因为 null 会导致 mysql 多一层判断。
  5. 使用 like 的时候如果是通配符 % 在最前面的话也会走的全表扫描。
    欢迎补充。

2.你刚才一直在提索引,把你知道的关于索引的一些技巧说下

  1. 要在区分度高的字段上建立索引,否则索引意义不大。
  2. 字符串建立索引要注意大小,索引长度过长,占用的空间也就越大,适当的可以截取进行索引,缺点是不能使用到覆盖索引,具体根据业务合理安排。
  3. 建立联合索引要知道最左前缀原则,举个例子( name, email, phone ),最终能走这个联合索引的一定只会是 ( name ),( name, email ),( name, email, phone ),其他只能走全表,需要根据业务合理设置联合索引的顺序。

3.索引底层是什么数据结构?

答:B+树。

4.为什么用的是B+树,不能使用红黑树或者其他的?

答:可以使用红黑树。但是这样的话可能会造成树的高度过高,意味着相同查询下,会进行更多的磁盘I/O,影响性能,而 B+ 树可以保持树的高度不至于过高。这道题答得不是很好,不仅仅是这样,欢迎补充。

5.你知道索引下推吗?

本质上是对普通索引需要回表的一种优化,也就是引擎层在对索引指针遍历的过程中,先做一些优先的判断,过滤掉不符合条件的,可以减少磁盘IO。

6.假设现在有人操作数据库,不小心执行错了语句,误删除了很多数据,这时候能恢复吗?咋么恢复。

答:首先,一定要开启 bin-log ,如果没有开启的话,可能就恢复不了。要看具体的文件系统是否能恢复。开启了 bin-log ,类型设置要设置成 row 或者 mixed ,不能设置 statement 。然后,如果是误删行的话,就可以把里面对应的删除事件换成插入事件,在备用库上执行。如果是误删表的话,可以先获取最近的一次全量备份,放到备库,然后拿出 bin-log , 除了不执行删除的事件,其他事件依次重放。

7.为什么不能设置成 statement ?

答:设置成 statement ,实际 bin-log 存储的是 sql 语句( 非具体删除的主键id ),这样如果是主从架构的话,主和从可能因为选择的索引不一样而导致主从不一致。

8.你刚才说到主从,那你说说主从运行的机制吧

答:首先主库还是要开启 bin-log , 从库先设置要连接的主库 change master…… 然后执行 start slave,这时候从库会创建两个线程,一个 io_thread ,主要负责连接主数据库。一个sql_thread 主要是负责执行中转日志语句。首先,主库接收到从库的同步请求,根据传递的 bin-log 文件名和开始同步的位置,发送二进制文件给从库,从库 io_thread 负责把接收到的数据放入到中转日志,然后 sql_thread 负责从中转日志读取解析执行,执行完成,更新同步的位置标志。

9.你知道主从延迟吗?有些时候延迟的时间还会很长。遇到这种情况咋么办?

答:这种问题,注意了。划重点。问你出现问题,寻找解决方案的时候,一定要对症下药,也就是说这个问题你可以这样考虑,什么情况下导致的主从延迟。
1.如果主库和从库服务器配置不一样,从库的差点,那么就可能导致延迟时间加长。这时候,换成相同的服务器配置服务器即可。
2.从库压力太大了。一般主从了,从库基本用来查询,比如可能运营或者开发者自己都在从库上进行一系列的 sql 操作。那简单呗。多配几个从库,分摊压力,一主多从。
3.大事务。比如 delete 这种语句 不 limit 限制一下,如果数据量过大,导致主库运行时都花费了长时间,再同步到从库,这个时间间隔过长。

设计模式

你知道哪些设计模式,你平常有使用到吗?可以结合你的业务场景说下吗?

答 这里我先举例平常使用 Laravel,里面就用到大量设计模式,比如门面,组合,装饰,观察者…… 具体场景带入,然后根据之前业务上的场景说了下……., 最后也说了设计模式不是银弹,只有在合适的场景使用合适的模式才能体现它的价值。

手写算法

给定一个已排序的数组和一个指定值,返回指定值在数组中的下标位置,如果不存在,返回把给定值插入到数组之后的下标位置。注意时间复杂度。

比如给定有序数组 [1,3,5,6] 给定值5.那么返回下标2.
给定有序数组[1,3,5,6] 给定值 7,返回下标4.

答:

    function searchInsert($nums, $target) {
        if (!count($nums))  return 0;
        $l=0;
        $r = count($nums)-1;
        while ($l <= $r){
            $middle = $l + (($r - $l) >> 1);
            if ($nums[$middle] == $target) return $middle;
            if ($nums[$middle] < $target){
                $l = $middle+1;
            }else{
                $r = $middle-1;
            }    
        }
        return $l;
    }

典型的可以使用二分,时间复杂度 O(log2n)。空间复杂度O(1)。

网络

1.传输层主要有哪些协议?

答:主要有 TCP 和 UDP 协议。他们的区别是 TCP 是需要连接的 会经过三次握手,而且可以保证消息的可靠性。UDP 是不需要连接的,不保证消息的可靠性。

2.你能大体说说 TCP 的三次握手吗?

答:首先服务器监听某个端口,客户端发起请求 携带syn数据包(第一次),服务端接收到这个数据包,返回 syn/ack 的数据包给客户端(第二次),最后客户端再次发送一个 ack 的数据包(第三次)。

4.为什么需要三次握手?

答:主要是为了确认双方接收是否正常。
第一次:客户端什么都不能确认。服务端能确认客户端的发送正常,自己的接收正常
第二次:客户端能确认自己的发送和接收正常,服务端的发送和接收正常。服务端能确认自己接收正常,客户端的发送正常。
第三次:全部都能确认了。

并发

假设现在有多个入口可以同时使用一个账户操作,这个账户只有十块钱,有哪些方法可以使得不超扣消费?开放性题目,只要能解决问题的就是好方案,没有唯一答案。

答:mysql:可以直接 where amount>=current_amount and amount>0 …… , 或者悲观锁 for update。redis:lua 脚本。php 层面可以利用文件锁,还可以使用队列的特性,只有一个消费的出口。

设计

如果我们公司有很多项目都有登录的功能,咋么设计?

答:需要把这个登录单独抽出来作为一个模块开发,类似于登录中心,所有的其他子系统登录都需要从这个系统中认证。

其他

1.看你项目里说到使用过swoole,也写点go,你可以说说他们协程上的区别吗?

答:设计上他们是一样的,主要区别在于,协程调度器模式。swoole 的协程调度器是单线程,go 的协程调度器是多线程。这就意味着,同一时刻 swoole 只有一个协程在运行,而 go 同一时刻可以多个协程在运行。所以在 swoole 协程中不需要对全局变量进行加锁。而且 swoole 本质是单线程多进程的,意味着它没有超全局的变量,仅仅是进程级别变量。而 go 多线程,多线程必然会存在临界变量锁的问题。当然,go 也提供了开箱即用的 sync 读写锁,或者你也可以直接使用通道来代替。

2.你可以说说 go 的 gmp 调度模型吗?

答:巴拉巴拉半天,自己都觉得没说清楚,好吧,我不是很了解。此时猜测面试官心里,早说不知道不就完事了吗

3.说说你们这个项目最难的点是哪个地方,你是咋么解决的?

那就要看你自己对项目的掌握程度以及这个项目的含金量了。

注:有私信加好友的,当然能啦。个人微信:1185079673。

本作品采用《CC 协议》,转载必须注明作者和本文链接
吴亲库里
本帖由系统于 2个月前 自动加精
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
讨论数量: 24

优秀

3个月前 评论
aidoudou 2个月前

看了都懂,就是面试的时候说不出来 :smile:

3个月前 评论
cowboy 2个月前
Dunk958 3个月前

请问大佬面向几K :joy:

3个月前 评论

没有问框架的内容吗 :joy:

3个月前 评论
Remember (楼主) 3个月前
ifconfig 2个月前

博主目前在哪?

3个月前 评论
自由与温暖是遥不可及的梦想

只有当自己 真的懂了之后 才会 更好的答出来

2个月前 评论

tcp 为什么是三次握手这个答案相当赞啊 之前每次被问到都说全双工, 感觉面试官都不清楚我在说啥

2个月前 评论
Remember (楼主) 2个月前
Remember (楼主) 2个月前
hldh214 (作者) 2个月前
panda-sir 2个月前
hldh214 (作者) 2个月前
php炎黄

楼主在哪个城市

2个月前 评论
hxd

这是什么城市,多少k的要求啊

2个月前 评论
Krisji

有点简单哈,哈哈可以看看这个博客:底层原理面试汇总

2个月前 评论

都是干货哈,最近也在刷题,先感谢一波

2个月前 评论

你们都在什么平台找工作啊

2个月前 评论

这种我猜在帝都25k的水平吧

2个月前 评论

微信公众号 库里的深夜食堂

2个月前 评论

感觉好多都不懂 :joy:

2个月前 评论

TCP 的三次握手说的有点问题

第一次 客户端发送正常 client 发送 syn ack

第二次 服务端接收正常 server 发送 syn ack+1

第三次 客户端接收正常,服务端发送正常 连接可靠

思考题 如果 123 有哪一步丢失了,怎么确保正常呢,机制是什么

2个月前 评论

除了数据被误删除,其他都能答上来。

想问问大佬开的多少K,借鉴一下?(因为我快4年没面试了)

2个月前 评论

学到了, mark一下

1个月前 评论
KangST

MySQL联合索引使用时不一定要使用顺序正确吧,index(a,b,c) where c and a 也是可以的吧。

1个月前 评论
馨竹之乡 1个月前
mingzaily 1个月前
KangST (作者) 1个月前
KangST (作者) 1个月前
KangST (作者) 1个月前

为什么用的是 B + 树,不能使用红黑树或者其他的?

  • 哈希表:

(1)不能做多字段查询。

(2)哈希索引无法完成排序(order by)。

(3)在有大量重复键值的情况下,哈希的效率会变低(哈希碰撞问题)。 哈希表中存放的数据不是有序的,因此不适合做区间查询,适用于只有等值查询的场景。

  • 二叉搜索树:

(1)二叉搜索树在某些情况下,会退化成一个包含n个节点的线性链表,查找效率极速降低。

(2)二叉搜索树指的是逻辑结构上的二叉搜索树,其物理实现有两种,也就是在外存的存储结构:第一种是顺序存储结构(数组),第二种是链式存储结构(链表)。这就导致了在逻辑上很近的节点(父子)在物理上可能很远,无法很好利用局部性原理和磁盘预读,因此,每次读取的磁盘页的数据中有许多是用不上的。I/O“渐进复杂度”跟树高h形成一种关系,为O(h),所以,才有所谓的树高越高,磁盘IO越频繁。

  • AVL和红黑树:

(1)维护平衡过程的成本代价很高,因为每次删除一个节点或者增加一个节点的话,需要一次或者多次的左旋,右旋等去维护“平衡”状态。

(2)AVL 树和红黑树基本都是存储在内存中才会使用的数据结构。在大规模数据存储的时候,红黑树往往出现由于树的深度过大而造成磁盘IO读写过于频繁,进而导致效率低下的情况。为什么会出现这样的情况,我们知道要获取磁盘上数据,必须先通过磁盘移动臂移动到数据所在的柱面,然后找到指定盘面,接着旋转盘面找到数据所在的磁道,最后对数据进行读写。磁盘IO代价主要花费在查找所需的柱面上,树的深度过大会造成磁盘IO频繁读写(见上面二叉搜索树)

  • B树和B+树:

(1)B-树/B+树 的特点就是每层节点数目非常多,层数很少,目的就是为了就少磁盘IO次数,但是B-树的每个节点都有data域(指针),这无疑增大了节点大小,说白了增加了磁盘IO次数(磁盘IO一次读出的数据量大小是固定的,单个数据变大,每次读出的就少,IO次数增多,一次IO很耗时),而B+树除了叶子节点其它节点并不存储数据,节点小,磁盘IO次数就少。这是优点之一。

(2)B+树所有的Data域在叶子节点,一般来说都会进行一个优化,就是将所有的叶子节点用指针串起来。这样遍历叶子节点就能获得全部数据,这样就能进行区间访问啦。在数据库中基于范围的查询是非常频繁的,而B树不支持这样的遍历操作。

1个月前 评论

为什么 TCP 连接需要三次握手?

The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion. —— RFC 793- Transmission Control Protocol

TCP 连接使用三次握手的首要原因 —— 为了阻止历史的重复连接初始化造成的混乱问题,防止使用 TCP 协议通信的双方建立了错误的连接。来自 为什么 TCP 建立连接需要三次握手

1个月前 评论

我选择跟HR battle 一下

file

1个月前 评论

满满的干活

1个月前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!