拼多多提前批，秒挂！

拼多多这个大厂想必大家都不陌生，出了名的薪资高待遇好（当然加班也多 haha），很多朋友挤破头皮都想冲进去。

最近拼多多也是开启提前批了，网申时间为2025 年 7 月 21 日至 8 月 24 日。今天就分享一下组织内部的朋友在拼多多的面经。

他艰难地通过了笔试，一面的面试问题他基本上都回答出来了，只有一两个问题说的不太好（因为面试官表情不太满意），但是面完还是直接挂了，大厂毕竟是大厂，竞争肯定是很激烈的，稍微没回答好就被别人比下去了，只能说再接再厉吧，下面开始分享面试题：

问题 1 和 2 就不多说了，可以根据这些问题提前整理自己项目相关的内容

问题 3：介绍一下 MySQL 的覆盖索引

可以这么理解：如果查询的所有字段（包括 select 的列和 where 条件的列）都包含在某个索引里，那这个索引就叫覆盖索引。举个例子，比如有个用户表user(id, name, age)，建了索引idx_name_age(name, age)。如果我查select name, age from user where name = '张三'，这时候不用回表查主键索引里的完整数据，直接通过idx_name_age就能拿到结果，这就是覆盖索引。好处很明显：减少 IO 操作，因为不用查两次索引（二级索引 + 主键索引），效率会高很多。实际工作中，我们有时候会故意加个联合索引包含查询需要的字段，就是为了用到覆盖索引。

问题 4：为什么 MySQL 索引用 B + 树而不是 B 树或哈希表？

主要从查询效率和场景适配来看：

• 先排除哈希表：哈希索引虽然等值查询快，但不支持范围查询（比如where age > 20），也不支持排序，而 MySQL 很多场景需要范围查，所以不合适。

• 再看 B 树和 B + 树的区别：B 树的每个节点（包括非叶子节点）都存数据，导致非叶子节点能存的索引数量少，树会比较高，查的时候磁盘 IO 次数多（因为索引存在磁盘上，树高对应 IO 次数）。而 B + 树只有叶子节点存数据，非叶子节点只存索引，所以同样大小的节点能存更多索引，树更矮，IO 次数少。而且 B + 树的叶子节点是用链表连起来的，范围查询时直接遍历链表就行，特别高效。MySQL 的索引本质是为了优化查询，尤其是范围查询和排序，B + 树刚好契合这些需求，所以选它。

问题 5：MySQL 中哪些情况不适合加索引？为什么？

这得结合索引的优缺点来看，索引能加速查询，但会拖慢插入 / 更新 / 删除（因为要维护索引结构），所以这些情况一般不加：

1. 表数据量特别小（比如就几百行）：全表扫描可能比走索引还快，加索引反而浪费空间。

2. 频繁更新的字段：比如订单状态，每次更新都要同步更新索引，会影响性能。

3. 区分度低的字段：比如性别（男 / 女），加了索引也过滤不了多少数据，查询时大概率还是全表扫，白占空间。

4. 太长的字段（比如 varchar (2000)）：索引会很大，占存储空间，而且比较时效率低，一般可以取前缀建索引。

5. where 条件里用函数处理的字段：比如where substr(name, 1, 3) = 'abc'，这时候索引用不上，加了也白加。

问题 6：生产环境中如何排查和优化慢查询？

我一般分几步来：

1. 先确认有没有慢查询：开启 MySQL 的慢查询日志（slow_query_log = 1），设置阈值（比如long_query_time = 1秒），超过这个时间的 SQL 会被记录到日志里。

2. 抓出慢查询后，用explain分析执行计划：看type（是否全表扫ALL）、key（是否用到索引）、rows（估计扫描行数）、Extra（有没有Using filesort、Using temporary这些耗时操作）。

3. 针对性优化：

4. 如果没走索引，看看是不是字段没加索引，或者索引失效了（比如用了!=、or、函数操作等），调整索引或 SQL。

5. 如果用到了索引但还是慢，可能是索引建得不合理（比如单字段索引不如联合索引），或者数据量太大，考虑分表分库。

6. 有Using filesort或Using temporary的话，可能是排序或分组操作导致的，优化排序字段或调整 SQL 逻辑。

7. 工具辅助：比如用pt-query-digest分析慢查询日志，找出最耗时的 SQL；实时排查可以用show processlist看当前运行的线程，有没有堵塞。

问题 7：Redis 缓存穿透、击穿、雪崩的区别是什么？各自有哪些解决办法？

这三个都是缓存出问题的场景，但原因和解决思路不一样：

• 缓存穿透：查一个根本不存在的数据（比如查 id=-1 的用户），缓存和数据库都没有，请求每次都打到数据库，可能压垮 DB。解决：① 用布隆过滤器提前过滤不存在的 key，直接返回；② 缓存空值（比如缓存 id=-1 的结果为 null，设置短期过期），避免重复查 DB。

• 缓存击穿：一个热点 key 突然过期了，这时候大量请求同时进来，都去查 DB，瞬间压垮 DB。解决：① 热点 key 设置永不过期；② 用互斥锁（比如 Redis 的 setnx），只让一个请求去查 DB，其他请求等结果更新到缓存后再查缓存。

• 缓存雪崩：某一时刻大量 key 集中过期，或者 Redis 集群挂了，请求全打到 DB，直接把 DB 搞崩。解决：① 过期时间加随机值（比如原本 1 小时，改成 1 小时 ±10 分钟），避免集中过期；② Redis 集群部署（主从 + 哨兵），防止单点挂掉；③ 服务端加熔断降级（比如用 Sentinel），超过阈值就返回默认值，保护 DB。

问题 8：Redis 的 key 过期删除机制是怎么实现的？

Redis 不是简单的 “过期就立刻删”，而是三种策略结合：

1. 定期删除：每隔一段时间（默认 100ms），随机抽一批过期的 key 检查，如果过期就删。好处是不用一直盯着，缺点是可能漏删（没抽到的过期 key 还在）。

2. 惰性删除：当你去查一个 key 时，Redis 才会检查它是否过期，如果过期就删掉并返回 null。这样能保证查到的都是没过期的，但如果一个过期 key 一直没人查，就会一直占内存。

3. 内存淘汰机制：当 Redis 内存达到maxmemory限制时，会根据配置的策略（比如 LRU 最近最少使用、LFU 最近最少频率使用）主动淘汰一些 key，包括过期的和没过期的。

这三种配合起来，既能避免频繁删除影响性能，又能防止内存被过期 key 占满，挺巧妙的。

问题 9：从输入 URL 到页面展示，整个过程涉及哪些网络操作？

大概分这么几步：

1. DNS 解析：把域名（比如www.pinduoduo.com）转成 IP 地址。先查本地缓存，没有就查 DNS 服务器，一级一级往上查（本地 DNS→根域名服务器→顶级域名服务器→权威服务器）。

2. 建立连接：如果是 HTTPS，先进行 TLS 握手（交换证书、协商加密算法）；然后 TCP 三次握手建立连接。

3. 发送请求：浏览器构造 HTTP 请求（方法、路径、头信息等），通过 TCP 发给服务器。

4. 服务器处理：服务器收到请求后，处理业务逻辑（比如查数据库、调用接口），生成响应（状态码、响应体等）发回来。

5. 接收响应：浏览器收到响应，解析 HTML、CSS、JS，渲染页面（构建 DOM 树、CSSOM 树，合成渲染树，绘制页面）。

6. 断开连接：如果 Connection 是 close，TCP 四次挥手断开连接；如果是 keep-alive，连接会保持一段时间复用。

问题 10：TCP 第三次握手时能否携带数据？为什么？

可以携带数据。

TCP 三次握手的过程是：客户端发 SYN→服务器回 SYN+ACK→客户端回 ACK。第三次握手是客户端发 ACK，这时候客户端已经处于ESTABLISHED状态（可以发送数据了），服务器收到第三次握手的 ACK 后也会进入ESTABLISHED状态（可以接收数据了）。所以理论上，第三次握手的报文里可以带上数据。

不过实际中一般不会带太多，因为如果数据很大，可能被攻击者利用来搞 SYN Flood 攻击（假装三次握手，发大量数据占服务器资源）。但从协议设计上来说，是允许的。

问题 11：分布式事务有哪些常见的解决方案？各自的适用场景是什么？

常见的有这么几种：

1. 2PC（两阶段提交）：分准备和提交阶段，协调者先让所有参与者准备，都 ok 了再统一提交。优点是强一致性，缺点是协调者挂了会阻塞，适合对一致性要求极高但并发不高的场景（比如金融核心交易）。

2. TCC（Try-Confirm-Cancel）：把业务拆成 Try（预留资源）、Confirm（确认执行）、Cancel（取消释放资源）三步。优点是灵活，不依赖数据库，缺点是业务侵入性高（要写三个接口），适合复杂业务场景（比如电商下单扣库存、减余额）。

3. 本地消息表：基于消息队列，每个服务本地有个消息表，操作业务时先写消息表，再发消息给其他服务，通过定时任务重试失败的消息。优点是实现简单，缺点是要维护消息表，适合一致性要求不高、允许最终一致的场景（比如物流状态同步）。

4. SAGA 模式：把长事务拆成多个短事务，每个短事务有对应的补偿事务，一个失败就触发补偿回滚。优点是支持长事务，缺点是补偿逻辑复杂，适合分布式服务调用链较长的场景（比如跨境电商多环节下单）。

问题 12：手撕力扣 239. 滑动窗口最大值（困难）

可以自己动手写一下，力扣上面的原题

问题 13：说出两个使用拼多多过程中不爽的点

这个问题留给大家，你们在用拼多多的时候有哪些感觉不爽的地方？

欢迎关注 ❤

我们搞了一个免费的面试真题共享群，互通有无，一起刷题进步。

没准能让你能刷到自己意向公司的最新面试题呢。

感兴趣的朋友们可以加我微信：wangzhongyang1993，备注：面试群。