顺丰 Java 后端二面：适配器设计、上传幂等与 InnoDB 回表优化

《面试题目》

1. 请做一下自我介绍。
2. 项目中如何设计统一数据模型，兼容不同来源、不同版本的数据格式？
3. 如何设计适配器，隔离外部数据格式变化对内部业务的影响？
4. 如何设计一个高质量的 Agent Skill？如何保证执行结果的准确性和可靠性？
5. 如何实现文件上传的幂等性和断点续传？
6. 文件上传时，整体哈希和分片哈希分别有什么作用？
7. 如果服务端已经成功处理请求，但响应在返回途中丢失，客户端应该如何处理？如何保证幂等性？
8. 项目中做过哪些慢 SQL 优化？介绍一个具体案例及排查过程。
9. 联合索引的字段顺序应该如何设计？最左前缀原则是什么？
10. 假设查询条件为 WHERE a = ? AND b = ? ORDER BY c，但联合索引只有 (b, c)，这个索引是否一定不能使用？为什么？
11. 什么是索引条件下推（ICP）？具体在哪一层执行？
12. InnoDB 使用索引条件下推过滤数据后，回表过程中还可能进行哪些优化？
13. 通过二级索引查询得到的主键 ID 是有序的还是无序的？为什么？
14. InnoDB 通过二级索引回表时，为什么可以先按照主键 ID 排序？
15. 按照主键 ID 排序后再回表，为什么能够提高查询效率？底层原理是什么？
16. 反问：部门主要负责哪些业务？

《参考解析》

统一数据模型 + 适配器：思路是「内部模型稳定，外部格式在边界翻译」。定义一个与来源无关的领域模型（字段按业务语义命名，不跟着任何一方的格式走），每个外部来源写一个适配器负责：解析原始格式、字段映射、枚举值归一、缺失值补默认、版本差异处理。变化被限制在适配器内部，核心逻辑不用改。要加一层校验：适配器输出后统一走 schema 校验，脏数据在这里被拦住而不是流进业务。

Agent Skill 的可靠性：Skill 要「可被判断对错」。设计上：输入输出都给严格 schema、把不可靠的自由文本判断改成结构化决策、给出明确的失败返回（信息不足要说不足而不是硬编）、关键动作要求确认。验证上：为每个 Skill 建一组典型用例 + 边界用例（缺参、超长、格式不对、语义模糊），跑回归；线上打点记录调用成功率与人工纠正率。

上传幂等与断点续传：幂等靠「内容指纹」，不是靠请求 id——同一个文件重复上传应该只产生一份。断点续传靠分片：客户端先请求「这个文件（按整体哈希）已上传了哪些分片」，服务端返回已存在的分片列表，客户端只传缺的；全部分片到齐后服务端按顺序合并并校验整体哈希。整体哈希的作用是文件身份（去重、校验完整性、秒传）；分片哈希的作用是分片级校验与断点续传的定位（哪个分片坏了只重传那一片）。合并阶段要幂等：用文件哈希做唯一键，重复合并直接返回已有结果。

响应丢失后的重试：这是「不知道成功没成功」的经典问题，客户端只能靠查询来确认而不是盲目重试。做法：请求带幂等键（或资源指纹），超时后先查「这个键对应的资源是否已存在」，存在就直接用，不存在才重发；服务端对同一幂等键返回同一结果（而不是报错）。前提是幂等键的存在性检查与写入要在同一个事务/唯一索引里完成。

慢 SQL 的排查过程：先用慢查询日志与 APM 定位到具体 SQL 和耗时分布（是偶发还是稳定慢），再 EXPLAIN 看执行计划（type、key、rows、Extra 里的 filesort/temporary），对照数据量与索引判断走没走对索引。常见修法：补/调整联合索引顺序、消除函数包裹与隐式类型转换（导致索引失效）、把 SELECT * 收窄成覆盖索引、大偏移分页改成游标分页、把多次查询合并成一次 JOIN 或批量查。改完要用同一份数据量的执行计划与耗时对比，而不是「感觉快了」。

联合索引顺序与最左前缀：设计原则是「等值条件在前、范围条件在后，选择性高的优先」。最左前缀是指索引可以按定义顺序的前缀被使用：(b, c) 能被 b、(b,c) 用，不能单独被 c 用。

WHERE a=? AND b=? ORDER BY c 配 (b, c)：这题的关键是「不一定不能用」。如果 b 的选择性足够高，优化器可以用 (b, c) 先按 b 定位、并且天然按 c 有序，省掉 filesort；a 则在回表后作为过滤条件。但如果 b 的匹配行数很多，优化器可能判断走索引回表的成本高于全表扫描，就变成全表扫描 + filesort。所以答案是：能用，但取决于优化器对 b 的基数与过滤率的估算，不是「一定不能用」。理想索引其实是 (a, b, c) 或 (b, a, c)（让 a、b 都是等值，c 保持有序）。

ICP：Index Condition Pushdown 是 MySQL 5.6 引入的优化：把「能用索引字段判断」的过滤条件下推到存储引擎层，在从二级索引取到记录后、回表之前先判断，不满足就直接跳过，从而减少回表次数。它作用在存储引擎层而不是 server 层，执行计划里 Extra 显示 Using index condition。注意它只适用于二级索引（聚簇索引已经在引擎层拿到整行），且条件下推的字段必须在该索引里。

回表还能做什么优化：ICP 之后可以「按主键排序再批量回表」——把命中的主键收集起来排序，让随机回表变成顺序回表，提升缓冲池命中率与磁盘预读效率。更进一步是索引覆盖：如果查询需要的列都在索引里，就完全不回表。

二级索引主键是否有序 / 为什么要排序：单个二级索引的叶子节点里，主键是按索引键有序、主键本身无序的（除非索引是 (k, id) 这种形式或索引键重复的情况）。跨多个范围扫描合并（如 index merge）时主键更是乱序。排序的意义是把随机 IO 变成顺序 IO：InnoDB 按主键聚簇，按主键递增顺序回表相当于顺序扫描聚簇索引的页，页面能被预读进 buffer pool 并复用，显著减少随机磁盘寻道。这是 MRR（Multi-Range Read）优化的核心思路。