在医疗电子病历系统中，如何设计数据库模型以支持高并发写入和复杂查询？请举例说明索引策略、分库分表策略及事务处理方案。
科大讯飞医学类难度：中等
答案
1) 【一句话结论】在医疗电子病历系统中，通过**索引优化（覆盖索引+复合索引）**提升查询效率、分库分表（按医院ID分库+按时间分表）降低单库压力、Saga模式保障跨库一致性（避免两阶段提交阻塞），并结合版本号字段实现不可篡改与可追溯，从而平衡高并发写入与复杂查询需求。
2) 【原理/概念讲解】高并发写入与复杂查询的核心矛盾是“写入多、查询多、数据量大”。
- 索引策略：索引是查询加速器，需平衡写入性能。覆盖索引（包含查询所有字段的索引）可减少I/O，适用于查询字段多的情况；复合索引（按查询频率排序字段顺序）提升多条件查询效率，如“患者ID+记录时间+状态”的复合索引。
- 分库分表策略：垂直分库（按业务模块拆库，如患者信息库、病历库）或水平分表（按时间/ID范围拆表，如按年月分表，或按医院ID分库）。水平分表需设计路由规则（如按时间范围分表，避免全表扫描）。
- 事务处理：医疗数据需强一致性（如病历修改跨库同步），需用分布式事务。两阶段提交易阻塞，采用Saga模式（将事务拆分为本地事务+消息队列补偿）或Seata AT模式（将分布式事务转化为本地事务），减少阻塞。
- 医疗特有机制：添加“版本号”字段（每次修改version+1），结合版本号索引加速版本查询，确保数据不可篡改和可追溯。
3) 【对比与适用场景】
| 策略类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 索引策略 | 为数据库表创建的查询加速结构 | - 覆盖索引：包含查询所有字段的索引，减少I/O <br>- 复合索引：按字段顺序排序的索引，提升多字段查询效率 | - 覆盖索引：高频查询字段多时（如按患者ID+时间范围查询病历）<br>- 复合索引：多条件查询（如按科室+时间+状态） | - 过度索引导致写入慢（每写入一条数据需更新所有索引）<br>- 复合索引字段顺序需按查询频率排序（如先按患者ID，再按时间） |
| 分库分表 | 按维度拆分数据库或表，降低单库压力 | - 垂直分库：按业务模块拆库（如患者信息库、病历库）<br>- 水平分表：按时间/ID范围拆表（如按年月分表，或按医院ID分库） | - 垂直分库：业务模块多，单库容量大（如患者信息库、病历库）<br>- 水平分表：数据量大，单表记录数多（如按时间分表，按医院ID分库） | - 水平分表需设计路由规则（如按时间范围分表，避免全表扫描）<br>- 垂直分库需跨库事务支持（如分布式事务） |
| 事务处理 | 保障跨库操作数据一致性的机制 | - 两阶段提交：强一致性，但阻塞严重（适用于短事务）<br>- Saga模式：最终一致性，通过补偿事务避免阻塞（适用于长事务） | - 两阶段提交：医疗数据强一致性要求（如病历修改需跨库同步）<br>- Saga模式：医疗场景的长事务（如批量修改病历） | - Saga模式需消息队列支撑，确保补偿事务执行<br>- 两阶段提交需协调库，增加系统复杂度 |
4) 【示例】
假设医疗电子病历系统有“患者记录表（patient_record）”，字段包括：patient_id（患者ID，主键）、record_time（记录时间，时间戳）、record_content（记录内容，文本）、status（状态，枚举：已审核/待审核/已归档）、hospital_id（医院ID，分库维度）、version（版本号，自增整数）。
- 索引策略：
- 主键索引：patient_id（自增ID，写入时自动生成）。
- 复合索引：创建索引 idx_patient_time_status (patient_id, record_time, status)，用于查询“按患者ID+时间范围+状态”的病历（如“患者A 2024-01-01 至 2024-01-31 已审核的病历”）。
- 覆盖索引：若查询仅需 patient_id、record_time、status，可创建覆盖索引 idx_patient_time_status (patient_id, record_time, status)，减少读取 record_content 的I/O。
- 分库分表：
- 分库：按 hospital_id 分库（如 hospital_1、hospital_2），每个医院的数据存入对应库，减少跨库查询压力。
- 分表：按 record_time 分表（如按年月分表，如 2024_01、2024_02），每个表存储对应时间段的记录，查询时仅扫描对应表。
- 事务处理：
当医生修改患者病历（如更新 record_content、status）时，采用“Saga模式”：- 本地事务1（hospital_1库）：更新 record_content、status 为“待提交”，并插入补偿事务记录（如“修改患者A的记录，状态待提交”）。
- 消息队列：发送“提交”消息到消息队列。
- 本地事务2（hospital_1库）：确认提交，更新 status 为“已提交”，删除补偿事务记录。
- 若本地事务1失败，补偿事务（本地事务3）执行：回滚 record_content、status 为原值，恢复补偿事务记录。
5) 【面试口播版答案】
“面试官您好，针对医疗电子病历系统的高并发写入和复杂查询需求，我的设计思路是：首先通过索引优化提升查询效率，比如为高频查询（如按患者ID+时间范围）创建复合索引，必要时用覆盖索引减少I/O；然后通过分库分表降低单库压力，按医院ID分库、按时间分表，避免单表数据过大；最后通过Saga模式保障跨库操作的一致性，将事务拆分为本地事务+消息队列补偿，避免两阶段提交的阻塞问题。同时，为满足医疗数据的不可篡改要求，我们在数据库中添加了版本号字段（每次修改version+1），结合版本号索引加速版本查询，确保数据可追溯且不可篡改。这样既能支持高并发写入，又能高效处理复杂查询。”（约90秒）
6) 【追问清单】
- 索引选择依据：如何判断哪些字段需要建索引？
回答要点：根据查询频率和字段基数（如患者ID是唯一主键，必建索引；记录时间字段高频查询，需建索引；记录内容字段不常查询，无需建索引）。 - 分表粒度设计：分表粒度（如按天/月/年）如何影响查询性能？
回答要点：按月分表比按天分表粒度大，查询时需扫描更多表，但减少表数量；按天分表粒度小，查询时需扫描更多表，但单表数据少，适合高频查询场景。 - 事务一致性保障：Saga模式的补偿事务如何保证最终一致性？
回答要点：通过消息队列传递状态，当本地事务失败时，补偿事务根据失败原因执行相反操作，确保数据最终一致。 - 医疗数据特殊要求：版本控制如何实现不可篡改？
回答要点：添加version字段，每次修改version+1，查询时按版本号过滤，确保只能读取到指定版本的数据，避免篡改。 - 高并发下的锁优化：如何避免索引或事务导致的锁竞争？
回答要点：使用“乐观锁”（通过版本号判断是否冲突），减少锁竞争；或采用“读写锁”（读多写少场景），读操作不阻塞写操作。
7) 【常见坑/雷区】
- 索引过度：过度建索引导致写入性能下降（如每写入一条数据需更新多个索引）。
- 分表粒度不当：分表粒度过细（如按小时分表）导致查询时需扫描大量表，性能下降；粒度过粗（如按年分表）导致单表数据过大，写入/查询效率低。
- 事务方案选择错误：使用两阶段提交时未考虑阻塞问题，导致高并发写入时事务阻塞；或未考虑医疗数据的强一致性要求，使用最终一致性方案导致数据不一致。
- 忽略医疗特性：未考虑病历数据的版本控制、不可篡改要求，导致数据可篡改或版本混乱。
- 分库分表路由规则缺失：水平分表时未设计路由规则（如按时间范围分表，未指定查询时间范围时的表选择逻辑），导致查询时全表扫描。