HIS系统中，门诊挂号、缴费等操作是高并发场景。请分析这些场景下数据库的性能瓶颈，并提出优化方案（如索引优化、读写分离、缓存策略等），并说明如何通过压力测试验证优化效果。
答案
1) 【一句话结论】高并发下门诊挂号、缴费的数据库性能瓶颈主要来自锁竞争（事务隔离级别影响）、I/O瓶颈及事务处理效率，需通过复合索引优化查询、读写分离分散读压力、缓存策略减少数据库访问，并通过压力测试（吞吐量、响应时间、资源利用率）验证优化效果。
2) 【原理/概念讲解】老师口吻解释：数据库在高并发场景下，大量事务同时操作挂号、缴费表，会导致锁竞争（行级锁/表锁），事务阻塞；事务隔离级别（如READ COMMITTED vs REPEATABLE READ）影响锁粒度：READ COMMITTED允许脏读，减少锁持有时间，降低竞争；而REPEATABLE READ需严格锁，可能加剧冲突。频繁的I/O操作（读取患者、科室信息）消耗磁盘I/O，成为瓶颈。缓存（如Redis）的作用是减少数据库访问，将热点数据（如常用科室、医生排班）存入内存，用户查询时先从缓存获取，若未命中再查数据库。类比：数据库是“核心仓库”，缓存是“前置仓库”，用户先去前置仓库拿，拿不到再去主仓库，减少主仓库压力。
3) 【对比与适用场景】
| 优化策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 复合索引 | 为多个字段创建组合索引（如科室ID+医生ID） | 提升多条件查询效率，减少全表扫描 | 查询科室和医生时（如科室ID+医生ID组合查询） | 需分析查询模式，避免过度索引；定期执行ANALYZE TABLE更新统计信息 |
| 读写分离 | 主库负责写，从库负责读 | 分散读压力，提升读性能 | 读多写少场景（如门诊挂号、缴费查询） | 需同步机制（如MySQL binlog），设置从库延迟（如≤1秒），或使用同步复制（如PXC）保证一致性 |
| 缓存策略（Redis） | 将热点数据存入内存缓存 | 响应速度极快（毫秒级），减少数据库压力 | 热门数据（如常用科室、医生排班） | 需设置淘汰策略（如LRU）、失效机制（如TTL），应对缓存击穿/雪崩（布隆过滤器+限流） |
4) 【示例】假设门诊挂号流程：用户查询科室医生（步骤1：查询科室表获取科室信息；步骤2：查询医生表获取医生信息；步骤3：选择医生后提交挂号，插入挂号表）。优化后：
- 复合索引：科室表按科室ID+医生ID建复合索引，加速多条件查询。
- 读写分离：主库处理写（插入挂号表），从库处理读（查询科室、医生信息）。
- 缓存策略：Redis缓存科室ID到名称、医生ID到排班信息。查询时，先查Redis，若为空则查数据库并缓存。
伪代码示例：
# 查询科室医生信息（复合索引+缓存）
科室医生 = redis.get(f"科室医生:{科室ID}:{医生ID}")
if not 科室医生:
sql = "select 科室表.科室名称, 医生表.排班信息 from 科室表 join 医生表 on 科室表.科室ID=医生表.科室ID where 科室表.科室ID=? and 医生表.医生ID=?"
科室医生 = db.query(sql, 科室ID, 医生ID)
redis.setex(f"科室医生:{科室ID}:{医生ID}", 3600, 科室医生) # 1小时过期
# 挂号操作：主库执行
db.write("insert into 挂号表 (患者ID, 医生ID, 挂号时间) values (?, ?, now())", 患者ID, 医生ID)
5) 【面试口播版答案】面试官您好，门诊挂号、缴费属于高并发场景，数据库性能瓶颈主要来自锁竞争（事务隔离级别影响）、I/O瓶颈及事务处理效率。首先，索引优化：对查询频繁的字段（如科室ID、医生ID）建复合索引，比如科室表按科室ID+医生ID组合索引，提升多条件查询速度。其次，读写分离：主库处理写操作（如挂号、缴费），从库处理读操作（如查询科室、医生信息），用MySQL binlog同步数据，分散读压力。然后，缓存策略：用Redis缓存热门数据，比如常用科室、医生排班信息，用户查询时先从Redis获取，若缓存未命中再查数据库，减少数据库压力。最后，通过压力测试验证，比如用JMeter模拟1000并发用户，测试响应时间（确保<2秒）、吞吐量（每秒处理请求数）、错误率（0%），并监控CPU、磁盘I/O利用率，确保优化方案在高并发下有效。
6) 【追问清单】
- 问题1：如何选择事务隔离级别来优化锁竞争？
回答要点：对于读多写少的高并发场景，可考虑使用READ COMMITTED隔离级别，减少锁持有时间，降低锁竞争；若需保证事务可重复读，可使用REPEATABLE READ，但需注意可能加剧锁竞争。 - 问题2：读写分离中从库延迟如何处理？
回答要点：从库延迟（如1秒）会导致读操作获取旧数据，可通过设置合理的延迟时间（如≤1秒），或使用同步复制技术（如PXC）减少延迟，或通过补偿机制（如异步更新）保证一致性。 - 问题3：缓存策略如何应对缓存击穿？
回答要点：设置布隆过滤器提前过滤不存在的数据，或使用互斥锁+空值缓存，避免大量请求查询不存在的数据，导致缓存和数据库压力过大。 - 问题4：压力测试中除了响应时间，还关注哪些指标？
回答要点：吞吐量（每秒处理请求数）、错误率（事务失败率）、资源利用率（CPU、内存、磁盘I/O使用率），这些指标能全面评估系统在高并发下的稳定性。 - 问题5：复合索引的维护方法？
回答要点：定期执行ANALYZE TABLE命令，更新表统计信息，确保查询优化器能正确选择索引，避免索引失效。
7) 【常见坑/雷区】
- 复合索引选择不当：如仅按单个字段建索引，导致多条件查询效率低，应分析查询模式，选择合适的字段组合。
- 读写分离配置不当：从库延迟导致数据不一致，或主从切换时数据丢失，需合理设置延迟时间（如≤1秒），或使用同步复制技术。
- 缓存未设置过期：导致缓存数据过时，用户看到旧数据，需设置合理的TTL（如1小时），并使用LRU淘汰策略。
- 缓存击穿：大量请求查询不存在的数据，导致缓存和数据库压力过大，需通过布隆过滤器或空值缓存解决。
- 事务隔离级别选择错误：如使用REPEATABLE READ导致锁竞争加剧，影响并发性能，需根据业务场景选择合适的隔离级别。