假设平台在高峰时段出现数据库查询延迟，请描述排查步骤（从监控指标到定位问题点），并给出可能的解决方案。

1) 【一句话结论】高峰时段数据库查询延迟的排查需从实时监控指标（响应时间、资源使用率）入手，逐步定位到查询复杂度、索引缺失、资源竞争等具体问题点，解决方案包括优化查询、添加索引、分库分表或引入缓存，优先解决高影响问题。

2) 【原理/概念讲解】数据库查询延迟的核心是查询执行效率问题，好比图书馆找书：若索引缺失（相当于没分类目录），即使书在，也会翻遍所有书架（全表扫描），导致时间变长。高峰时段高并发下，CPU、IO等资源竞争加剧，进一步拖慢响应。排查需遵循“指标异常→问题定位→解决方案”的链路，从“数据”出发逐步缩小范围。

3) 【对比与适用场景】

方法	定义	特性	使用场景	注意点
监控指标	实时收集系统运行数据（响应时间、QPS、资源使用率）	实时性高，快速发现异常	高峰时段实时监控，定位异常开始时间	需提前配置关键指标，避免遗漏
日志分析	历史操作日志（SQL执行计划、错误信息）	历史数据，追溯根源	分析异常时段慢查询，找出执行计划	需定期归档日志，避免数据丢失
压力测试	模拟高并发场景下的系统表现	可控性高，验证方案效果	验证优化后系统稳定性	测试环境需与生产环境一致

4) 【示例】
伪代码模拟高峰时段查询请求：

// 高峰时段用户查询热门商品（假设数据库表products无category索引）
GET /api/products?category=electronics&limit=20
// 对应SQL：SELECT * FROM products WHERE category='electronics' LIMIT 20  
// 监控指标：响应时间从200ms飙升至2s，CPU使用率从30%升至80%，IO等待时间增加  

5) 【面试口播版答案】
面试官您好，高峰时段数据库查询延迟的排查，我会从监控指标开始，逐步定位问题点，再给出解决方案。首先，我会查看实时监控指标，比如响应时间、QPS、CPU/内存使用率，发现高峰时段响应时间显著上升（如从200ms到2s），同时CPU使用率从30%升至80%，说明资源竞争严重。接下来，分析慢查询日志，找出执行时间超过1秒的SQL（如SELECT * FROM orders WHERE user_id=?），执行计划显示全表扫描，因为缺少user_id索引。然后，检查数据库连接池状态，发现连接数已达到上限，导致新请求排队。解决方案方面，优先添加索引（如user_id索引），优化查询语句（去掉不必要的*，改为SELECT id, product_name），增加数据库连接池大小，或者引入Redis缓存热门商品数据。这样能快速缓解高峰时段的查询延迟。

6) 【追问清单】

• 问：为什么从监控指标开始而不是直接看日志？
  答：监控指标能实时发现异常，快速定位问题发生的时间点，而日志是历史数据，分析多个时间段的日志效率较低。
• 问：如何区分是数据库问题还是应用层问题？
  答：通过监控应用层接口响应时间，若应用层响应时间正常但数据库查询时间变长，则数据库是瓶颈；若应用层响应时间也变长，则可能是应用层处理逻辑或网络问题。
• 问：解决方案的优先级如何确定？
  答：优先解决影响最大的问题，比如索引缺失导致的全表扫描（根源问题）；其次是增加资源（如连接池、缓存），作为临时缓解措施，需结合业务调整。
• 问：如果优化后问题依旧，下一步怎么办？
  答：考虑分库分表（将数据分散到多库实例），降低单库压力；或优化数据库架构（如读写分离，将读操作分发到从库）。

7) 【常见坑/雷区】

• 坑1：只说监控指标而不具体，比如“看监控”，未说明具体看响应时间、资源使用率等关键指标。
• 坑2：解决方案不具体，比如“优化查询”，未提及具体措施（如添加索引、改SQL）。
• 坑3：忽略资源竞争，仅关注查询本身，导致排查不全面（高峰时段资源不足是延迟主因）。
• 坑4：未考虑缓存，对于热点数据直接查询数据库，未利用缓存减少数据库压力。
• 坑5：未区分慢查询和正常查询，仅看平均响应时间，无法定位具体问题点。