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

其实最近还在职,不过处于辞职交接状态,就挂了简历,但是没投。看到有邀约的,就和自己高度匹配的几家面试了,陆续拿到了几个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 协议》,转载必须注明作者和本文链接
吴亲库里
本帖由系统于 3年前 自动加精
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
讨论数量: 40

为什么用的是 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树不支持这样的遍历操作。

3年前 评论

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

3年前 评论

我选择跟HR battle 一下

file

3年前 评论

为什么 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 建立连接需要三次握手

3年前 评论

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

3年前 评论
馨竹之乡 3年前
mingzaily 3年前
KangST (作者) 3年前
KangST (作者) 3年前
KangST (作者) 3年前
CRAYON 3年前
lar_cainiao 3年前

学到了, mark一下

3年前 评论

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

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

3年前 评论

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

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

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

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

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

3年前 评论

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

3年前 评论
YeMou

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

3年前 评论

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

3年前 评论

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

3年前 评论
php炎黄

楼主在哪个城市

3年前 评论

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

3年前 评论
Remember (楼主) 3年前
Remember (楼主) 3年前
hldh214 (作者) 3年前
panda-sir 3年前
hldh214 (作者) 3年前
自由与温暖是遥不可及的梦想

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

3年前 评论

博主目前在哪?

3年前 评论

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

3年前 评论
Remember (楼主) 3年前
ifconfig 3年前

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

3年前 评论
cowboy 3年前
Dunk958 3年前

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!
未填写
文章
46
粉丝
117
喜欢
493
收藏
604
排名:177
访问:5.5 万
私信
所有博文
社区赞助商