后端接口性能优化：从 15.8 秒到 300 毫秒

《面试题目》

1. 讲一下你怎么把接口性能从 15.8 秒优化到 300 毫秒的？
2. 这个接口的业务逻辑是什么样的？为什么说它不是加个索引就能解决的问题？
3. 你是怎么定位到耗时瓶颈的？各个环节的平均耗时分别花在哪里？
4. 与需求方对齐业务这一步拿到了什么结论？为什么不能直接做组内截断、少返回数据？
5. 具体对代码动了哪些刀？每项优化分别解决什么问题？
6. 一个场景开关为什么能把平均 1.8 秒的耗时再压到 300 毫秒？

《参考解析》

1. 性能优化的第一原则：先测量、再修改。不要凭经验猜哪里慢，先用 Arthas 的 trace 命令连续抓几次调用，拿到各个环节的平均耗时，让数据决定动哪里。这个案例里最花时间的不是 SQL，而是远程调用和 25.8MB 的巨无霸响应体，如果一上来就去调 SQL，方向从一开始就错了。
2. 先看业务语义，再动代码：和需求方确认「标签下能不能只返回指定上限的书籍」这一步很重要，因为如果业务允许截断，改动量最小、收益最大。这次的答复是某些场景确实要全量返回，那就把优化方向转到减少无效计算上。面试时把这段讲出来，能体现你不是只会改代码。
3. 过滤前置，缩小数据集：链路里原本有远程合并、补充信息这类重操作，排在过滤之前，等于只想要 1% 的数据也要先把 100% 的数据全处理一遍再丢掉 99%。把过滤逻辑整体前移，让重活只作用在过滤后的小数据集上，这一步常常是提升最大、最容易被忽略的。
4. 精简 SQL 与缓存策略：查询语句 select 的字段远多于接口真正需要的，新增精准查询后数据库返回的字段直接砍半，网络传输和反序列化都省了。缓存上把大书店下的书籍、书籍标签关系全量写进 Redis 并在增删改时增量更新，过滤就降到毫秒级，同时避免了缓存击穿；要注意的是快照的完整性和增量更新的一致性，一旦漏更新就会出现数据对不上的问题。
5. 隔离数据与场景开关：远程调用的数据要求 Dubbo 提供方自己加缓存，而不是我方缓存别的领域的数据，否则数据归属混乱、对方一改我方就跟着脏。场景开关则是把「某个场景不需要返回标签下书籍明细」这个业务事实固化成配置，避免为不需要的数据付出代价；上线前要把开关默认值和灰度范围想清楚。