请描述一次你处理过的系统高并发问题（如某产品大促期间，系统响应变慢或崩溃），你是如何分析、定位并解决的？
答案
1) 【一句话结论】：在电商大促期间，系统因核心订单表高并发导致行级锁竞争，通过给status列加索引并优化SQL（利用索引过滤），锁等待时间从100ms降至1ms，系统QPS从5万提升至15万，响应时间从2秒降至0.3秒；后续补充Redis缓存订单状态（空值缓存+过期时间5秒），进一步优化性能。
2) 【原理/概念讲解】：高并发下系统性能瓶颈常源于资源竞争，核心是数据库行级锁。数据库的行级锁可类比为“电影院票务系统”：当多个用户同时抢同一张票（更新同一订单），锁会阻塞其他请求，导致队列积压。若锁竞争严重，系统会因等待锁超时而响应变慢或崩溃。关键监控指标包括MySQL的InnoDB_row_lock_waits（锁等待事件次数）、慢查询日志中锁等待时间占比。锁竞争的根源是高并发下多个事务同时访问同一行数据，导致锁队列积压。
3) 【对比与适用场景】：对比数据库优化手段（索引、分库分表）和缓存优化（穿透、雪崩）：
| 方法 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 添加索引 | 为列创建索引，加速查询并减少锁竞争 | 提升查询速度，减少锁等待时间 | 主键、高并发更新列（如订单状态） | 避免过度索引，影响写性能（如索引过多导致插入/更新变慢） |
| 分库分表 | 按业务或数据量拆分数据库表 | 跨库查询复杂，需分布式事务 | 数据量极大（如百万级订单，单表数据量超TB） | 需要分布式事务解决方案（如两阶段提交），增加系统复杂度 |
| 缓存穿透 | 对不存在的数据查询，缓存无命中，请求直接到数据库 | 增加数据库压力，可能导致雪崩 | 热点数据（如秒杀商品ID） | 设置空值缓存（缓存null值），避免缓存穿透 |
| 缓存雪崩 | 大量缓存同时过期，瞬间流量激增到数据库 | 瞬间数据库压力激增 | 热点数据（如活动页、秒杀商品） | 设置过期时间随机化（如±10%随机），避免集中过期 |
4) 【示例】：假设订单系统表结构：order(id, user_id, product_id, status, create_time)，大促时请求量从平时1万QPS升至50万QPS。监控发现order表的update操作（修改订单状态为“已支付”）响应时间从1ms升至200ms，日志显示“InnoDB row lock wait”事件频繁。分析：SQL为UPDATE order SET status='paid' WHERE id=? AND user_id=? AND status='pending'，因id和user_id组合是唯一键，高并发下多个请求同时更新同一订单，导致行级锁竞争。优化：1. 给status列加索引（CREATE INDEX idx_status ON order (status)）；2. 优化SQL为UPDATE order SET status='paid' WHERE id=? AND status='pending'（利用索引过滤，减少锁竞争范围）；优化后，锁等待时间从100ms降至1ms，QPS从5万提升至15万，响应时间从2秒降至0.3秒。后续补充Redis缓存订单状态，缓存key为order_status:{id}，过期时间5秒，空值缓存（若订单不存在则缓存null），避免缓存穿透。
5) 【面试口播版答案】：好的，面试官。我处理过一次产品大促的系统高并发问题。当时是公司电商平台的秒杀活动，系统响应时间从平时的0.5秒飙升至5秒，部分用户请求超时。首先，我查看系统监控指标，发现数据库慢查询日志中，UPDATE order SET status='paid' WHERE id=?的锁等待时间占比超80%，判断是数据库行级锁竞争导致的性能瓶颈。接着，分析SQL执行计划，发现该SQL在更新时需要获取行级锁，高并发下多个请求同时更新同一订单，导致锁队列积压。解决方案是给status列添加索引（CREATE INDEX idx_status ON order (status)），并优化SQL为UPDATE order SET status='paid' WHERE id=? AND status='pending'（利用索引过滤，减少锁竞争），优化后锁等待时间从100ms降到1ms，系统QPS从5万提升至15万，响应时间恢复到0.3秒以内。整个过程是通过监控定位问题，分析SQL执行计划找到锁竞争点，通过索引优化解决资源竞争。后续还补充了Redis缓存订单状态，缓存过期5秒，空值缓存避免穿透，进一步提升了性能。
6) 【追问清单】：
- 问：为什么选择加索引而不是分库分表？答：当时订单数据量约100万，分库分表需要重新设计表结构，而加索引能快速解决当前锁竞争问题，且不影响现有业务逻辑。
- 问：优化后是否考虑过缓存？答：是的，后续补充了Redis缓存订单状态，缓存key为
order_status:{id}，过期时间5秒，空值缓存避免缓存穿透，进一步提升了性能。 - 问：如果锁竞争更严重，比如需要分库分表，你会怎么处理？答：会先评估数据分布，按订单ID哈希分库，每个库存储部分订单，然后优化SQL为跨库查询（如使用ShardingSphere），并实现分布式事务（如两阶段提交），但当时问题已解决，所以未实施。
- 问：锁等待时间具体如何计算的？答：通过MySQL的
SHOW GLOBAL STATUS LIKE 'Innodb_row_lock_waits'查看，数值越高说明锁竞争越严重。
7) 【常见坑/雷区】：
- 只说问题不提解决：比如只说系统慢，没说具体原因和解决方法，显得分析能力不足。
- 优化方法错误：比如只加缓存没解决锁问题，或者加索引但没优化SQL，导致效果不明显。
- 忽略监控指标：比如只看响应时间，没看锁等待事件，导致定位不到根本原因。
- 忽略缓存雪崩：比如优化后加缓存，但没设置过期时间随机化，导致缓存大量过期，再次引发高并发。
- 忽略业务场景：比如分库分表时没考虑数据一致性，导致事务失败。