描述一个你处理过的复杂技术问题，比如系统在高并发下出现性能瓶颈，请说明诊断过程、定位原因及解决方案。

1) 【一句话结论】当时处理的高并发性能瓶颈问题，核心是数据库查询因缺少索引导致全表扫描，通过添加索引并配合缓存优化，使查询延迟从5秒降至50ms，并发量提升3倍。

2) 【原理/概念讲解】高并发下性能瓶颈通常源于系统资源瓶颈（CPU、内存、I/O、数据库等），需采用“分层诊断法”：从系统层面（监控CPU/内存/网络）、应用层面（日志分析请求路径）、数据库层面（SQL执行计划分析）逐步定位。比如，把系统比作流水线，每个环节（如数据库查询）是工序，若某工序效率低（全表扫描），会导致整个流水线卡顿，需检查该工序的瓶颈（索引缺失）。

3) 【对比与适用场景】

性能优化手段	定义	特性	适用场景	注意点
数据库索引优化	为数据库表字段创建索引，加速查询	提升查询效率，但增加写入成本	查询条件频繁、数据量大的场景（如主键、外键、常用查询列）	索引过多会增加磁盘空间和写入时间，需权衡
缓存策略（如Redis）	将热点数据存储在内存中，减少数据库访问	响应快，但需考虑缓存一致性和过期策略	高频读低频写、数据不常变动的场景（如用户信息、商品列表）	缓存击穿、雪崩风险，需结合数据库做读写分离

4) 【示例】假设系统是电商订单查询模块，秒杀活动时用户查询订单的SQL为SELECT * FROM orders WHERE user_id = ? AND order_time > ?，因user_id和order_time列无索引导致全表扫描。

• 诊断：通过系统监控（Prometheus）发现数据库查询延迟占90%，应用日志显示大量相同SQL。用MySQL的EXPLAIN分析，确认全表扫描。
• 优化：添加复合索引INDEX (user_id, order_time)，并使用Redis缓存热点订单数据（如最近30分钟内查询多的订单）。
• 结果：查询延迟从5秒降至50ms，并发量从1000QPS提升至3000QPS。

5) 【面试口播版答案】我当时负责的系统中，高并发下用户查询订单响应时间从500ms飙升至5秒，用户反馈卡顿。首先，我用系统监控工具（Prometheus+Grafana）看到数据库查询延迟占90%，接着检查应用日志，发现大量相同SQL语句。用MySQL的EXPLAIN分析，发现主键列无索引导致全表扫描。解决方案是在数据库添加复合索引，并缓存热点数据。优化后，查询延迟降到50ms，并发量提升3倍，用户反馈恢复正常。

6) 【追问清单】

• 问：优化索引后，数据库写入性能有没有影响？
  答：会轻微增加写入成本，但通过监控发现写入延迟仅增加10%，不影响整体性能。
• 问：如果数据库资源不足，如何进一步优化？
  答：考虑水平扩展数据库（分库分表），或引入读写分离，将读请求分到从库。
• 问：是否测试了索引的负面影响？比如索引维护成本？
  答：测试了，索引维护成本约占总写入时间的5%，在秒杀等高并发场景下，写入量有限，影响可接受。
• 问：是否考虑了缓存策略？比如Redis的缓存击穿？
  答：是的，使用了Redis缓存，并设置了过期时间，同时结合数据库做读写分离，避免缓存击穿。
• 问：如果问题不是索引，而是CPU瓶颈，你会怎么处理？
  答：会检查CPU使用率高的模块，比如查询处理逻辑，优化算法（如分页查询改为索引覆盖查询），或增加服务器CPU资源。

7) 【常见坑/雷区】

• 坑1：只说优化了索引，没提监控验证效果，导致面试官质疑是否真的解决了问题。
• 坑2：忽略其他瓶颈，比如网络延迟，直接归因于数据库，显得分析不全面。
• 坑3：假设所有查询都适合索引，没考虑索引的维护成本，比如高并发写入场景下，索引可能成为瓶颈。
• 坑4：没说明诊断步骤的顺序，比如先查系统监控再查日志，顺序混乱，显得逻辑不清晰。
• 坑5：解决方案过于简单，比如只加索引，没考虑缓存或数据库分库分表，显得优化方案不全面。