描述一次解决投放策略调整导致系统响应时间增加的问题，具体步骤：问题定位（日志分析、监控指标）、原因分析（数据库查询慢、缓存未命中）、解决方案（优化SQL、增加缓存、调整索引）。

1) 【一句话结论】通过日志与监控定位到投放策略调整后系统响应时间增加，原因是数据库查询因索引缺失导致全表扫描且缓存未命中，通过优化SQL（加索引）、增加缓存（Redis）及调整缓存策略后，系统响应时间恢复至正常水平。

2) 【原理/概念讲解】
日志分析就像查看系统的“日记”，记录每个请求的执行细节（如SQL语句、耗时），能精准定位到慢查询的具体位置；监控指标（如QPS、响应时间、数据库连接数）是系统的“体温计”，反映整体性能状态。数据库查询慢通常因索引缺失导致全表扫描（如WHERE条件未加索引），而缓存未命中则意味着热点数据未存储在内存中，每次请求都需回数据库，增加延迟。优化SQL的核心是减少查询复杂度，调整索引则是提升数据检索效率，缓存则是通过内存存储热点数据，降低数据库压力。

3) 【对比与适用场景】

方法	定义	特性	使用场景	注意点
优化SQL（加索引）	为数据库表字段添加索引，加速数据检索	提升读性能，减少全表扫描	查询条件频繁，数据量大	索引过多影响写性能（如INSERT/UPDATE时需更新索引）
增加缓存（如Redis）	将热点数据存储在内存中，快速访问	内存存储，访问速度极快	高频查询，数据不常变	需处理缓存击穿（热点数据失效时大量请求落库）、缓存雪崩（大量数据同时过期）
调整缓存策略（如过期时间）	设置缓存数据的生命周期	控制数据新鲜度	数据更新频率不同	过期时间太短导致频繁查询数据库，太长导致数据过时

4) 【示例】
假设投放策略调整后，系统需查询用户历史投放记录，原SQL为：

SELECT * FROM user_campaigns WHERE user_id = ? ORDER BY start_time DESC;

该SQL因user_id未加索引，导致全表扫描（执行计划显示“TABLE SCAN”），且未使用缓存，每次请求都回数据库。优化后：

• 为user_id字段添加索引；
• 使用Redis缓存查询结果，缓存键为campaigns:user_id，过期时间5分钟；
• 请求时先检查Redis，命中则返回，否则查询数据库并缓存结果。
  调整后，数据库查询从全表扫描变为索引扫描（执行计划显示“INDEX SCAN”），响应时间从800ms降至200ms。

5) 【面试口播版答案】
当时我们投放策略调整后，系统响应时间突然从200ms涨到800ms。首先，通过监控发现QPS下降，响应时间指标异常，接着查看日志，发现大量慢查询日志，具体是查询用户历史投放记录的SQL执行时间过长。定位到原因是数据库查询因user_id索引缺失导致全表扫描，且缓存未命中，每次请求都回数据库。解决的话，先为user_id字段加索引，优化SQL；然后增加Redis缓存，缓存查询结果，设置5分钟过期时间。调整后，响应时间回到200ms以内，系统恢复正常。

6) 【追问清单】

1. 为什么先分析日志而不是直接看监控？
   回答要点：监控是宏观指标（如整体响应时间、QPS），日志能更具体地看到每个请求的SQL执行细节（如耗时、执行计划），精准定位到慢查询的具体位置。
2. 缓存如何解决？有没有考虑缓存击穿？
   回答要点：缓存通过内存存储热点数据，减少数据库压力。缓存击穿是指热点数据失效时大量请求落库，可通过设置互斥锁或热点数据预热（提前将数据放入缓存）避免。
3. 优化SQL后，有没有影响其他功能？
   回答要点：优化SQL（加索引）主要影响读性能，对写性能影响较小（索引更新开销可接受），需验证写操作（如插入新投放记录）的延迟是否在可接受范围内。
4. 调整索引后，数据库写性能有没有变化？
   回答要点：索引会增加写操作的开销（如INSERT/UPDATE时需更新索引），但通过调整索引（如选择合适的索引类型，避免冗余索引），可平衡读/写性能。
5. 如果缓存失效怎么办？
   回答要点：缓存失效时，请求会回数据库，此时可通过监控预警，及时更新缓存或调整缓存策略（如缩短过期时间），避免系统压力骤增。

7) 【常见坑/雷区】

1. 忽略缓存预热：直接上线缓存策略，导致初始阶段缓存未命中，系统压力骤增。
2. 优化SQL时未考虑索引维护成本：为所有字段加索引，导致写性能下降，甚至引发死锁。
3. 缓存策略设置不当：过期时间太短导致频繁查询数据库，太长导致数据过时。
4. 未验证优化效果：只优化SQL/加索引，未通过压力测试或监控验证响应时间是否恢复。
5. 忽略分布式缓存一致性：多节点缓存未同步，导致数据不一致（如不同节点返回不同数据）。