4.9虾皮一面：

1、自我介绍 2、定时任务，同步到层级树，优化的是什么问题，优化前是什么，优化后是什么，怎么优化的？ 实时拉取：中继转发（）数据量大，数据清洗，提前构建层级树，

3、为什么实时拉取会那么慢？ 全量数据量+多次网络请求 4、实时拉取为什么需要全量，10w的数据量的流量大小 5、中继转发为什么会慢，网络流量+限速，有没有做过评估？

6、3～4s的瓶颈在哪？

7、内网，内网与外网是怎么联系

8、定这个方案需要考虑哪些点

9、时延，数据的存储，数据的强一致性问题

10、实时性要求不高

11、层级树，怎么存，什么查询场景

12、Redis没有树结构，怎么存储

13、全量给前端

14、数据量大了，该怎么做？ hash，每一层存储一个hash结构 10w 条要拆分存储，避免大 key。

15、怎么查

16、业务线的QPS：3w？？？ 3k

17、你们之前怎么设计的这个原方案

17、工单多条件查询：有什么性能问题，怎么优化的 回答太复杂了。。。

18、大的联合索引包含哪些字段

19、数据量：3kw

20、怎么设计的

21、联合索引是否命中索引

22、什么是跳跃扫描机制

23、三种条件不命中索引

24、哪三个字段

25、具体case说明？

26、觉得维护性怎么样，如果以后查询条件多了，怎么去维护？ 查询维度多了怎么办？ 1、覆盖索引；冷热数据分离（平时查询大多是热点数据，90% 查询最近7天，）；按时间分表；如果查询非常复杂：用ES 工单看板存在多条件组合查询场景，原有长联合索引在查询条件不固定时依赖 MySQL 的 Index Skip Scan，导致扫描次数增加，P99 延迟较高。针对该问题将长联合索引拆分为多个高选择性短联合索引，使不同查询模式命中对应索引，优化执行计划为 index range scan，从而降低长尾延迟。在压测环境下 P99 查询延迟降低 80%+。当数据量继续增大时，若持续增加索引会导致写入性能下降、索引占用内存增加以及优化器误选索引等问题，因此后续通过冷热数据分离、时间分表及覆盖索引等方式进一步优化查询性能。

A：分库分表、Redis存储热点数据

27、分库分表：多维查询需要带上分库键

28、Redis和MySQL的事物有什么区别 Redis的原子性怎么保证 Redis是不支持回滚的没有udolog，只有部分成功和失败（只保证批量执行） Redis事物：

MULTI  
命令入队  
EXEC

Redis原子性：1️⃣ 单线程模型 2️⃣ 命令原子执行 3️⃣ Lua脚本原子执行

29、coding： O（n）查询中位数