针对智慧医疗的电子病历系统，设计一个优化查询性能的策略，特别是针对复杂查询（如按医生ID、时间范围、疾病类型查询患者记录）。请说明索引设计、分库分表策略以及查询优化方法。
科大讯飞设计类难度：中等
答案
1) 【一句话结论】针对智慧医疗电子病历的复杂查询（多维度组合查询），通过构建多维度联合索引、分库分表（按医生ID/时间范围分片）及查询优化（预聚合、缓存），可显著提升查询性能。
2) 【原理/概念讲解】
- 索引设计：电子病历查询常涉及医生ID、时间范围、疾病类型等多字段组合，单字段索引无法高效处理多条件查询。因此采用联合索引（如（doctor_id, record_time, disease_type）），原理是数据库通过索引树快速定位满足多个条件的记录，类比图书馆按“作者+出版年份+书名”联合索引查找书籍，比单独按作者或年份查找更高效。
- 分库分表策略：当数据量巨大时，单库单表性能会瓶颈。采用水平分片（按业务键如doctor_id拆分库，每个医生数据单独存储，减少单表压力，类比大型超市按商品类别分成多个分店）和垂直分片（按时间维度如年/月拆分表，适合时间范围查询，避免数据膨胀）。
- 查询优化方法：通过预聚合（提前计算常用查询结果，如按医生ID统计每月记录数，存储在统计表中）和缓存（将热点查询结果缓存，如最近10次查询结果，下次查询相同组合时直接返回），减少实时计算压力，类比提前打印常用报表，避免每次查询都重新计算。
3) 【对比与适用场景】
| 对比项 | 联合索引（多字段索引） | 单字段索引 |
|---|---|---|
| 定义 | 包含多个字段的索引结构 | 仅针对单个字段的索引结构 |
| 特性 | 支持多条件查询，查询效率高 | 仅支持单条件查询，多条件需多索引 |
| 使用场景 | 复杂查询（多字段组合） | 简单查询（单字段筛选） |
| 注意点 | 字段顺序影响查询效率（按查询频率排序） | 无需考虑字段顺序 |
| 对比项 | 水平分片（按医生ID） | 垂直分片（按时间范围） |
|---|---|---|
| 定义 | 按业务键（如doctor_id）拆分表 | 按时间维度拆分表（如按年/月） |
| 特性 | 每个分片数据量小，适合关联查询 | 时间维度数据增长快，适合按时间查询 |
| 使用场景 | 多维度关联查询（如医生+时间） | 时间范围查询（如近30天记录） |
| 注意点 | 需保证关联字段一致性（如医生ID） | 时间字段需统一，避免跨表查询复杂 |
4) 【示例】
假设电子病历表结构为：patient_record (id, patient_id, doctor_id, record_time, disease_type, content)。
- 索引设计：创建联合索引
idx_doctor_time_disease (doctor_id, record_time, disease_type)。 - 分库分表：按
doctor_id水平分库（每个医生一个库），每个库内按record_time按年分表（如2024年表为patient_record_2024）。 - 查询优化：对于“按医生ID=1001、时间2024-01-01至2024-01-31、疾病类型‘感冒’查询”的复杂查询，先通过联合索引定位该医生在该时间范围内的记录，再过滤疾病类型。预聚合示例：提前计算每个医生每月的记录数，存储在
doctor_monthly_stats表中，查询时直接读取该表。缓存示例：将最近10次查询（如不同医生+时间范围的组合）结果缓存，下次查询相同组合时直接返回缓存结果。
5) 【面试口播版答案】
面试官您好，针对智慧医疗电子病历的复杂查询优化，我的核心思路是通过“多维度联合索引+分库分表+查询优化”的组合策略提升性能。首先，索引设计上，由于查询常涉及医生ID、时间范围、疾病类型等多字段组合，我们采用联合索引（如（doctor_id, record_time, disease_type）），这样数据库能通过索引树快速定位满足多个条件的记录，比单字段索引更高效，就像图书馆按“作者+出版年份+书名”联合索引查找书籍，比单独按作者或年份查找更直接。其次，分库分表策略，当数据量巨大时，单库单表性能会瓶颈，我们采用水平分片（按医生ID分库），每个医生数据单独存储，减少单表查询压力，类比大型超市按商品类别分成多个分店，顾客找商品更快；同时按时间范围垂直分表（如按年/月），适合时间维度查询，避免数据膨胀。然后查询优化，通过预聚合（提前计算常用查询结果，如按医生ID统计每月记录数）和缓存（缓存热点查询结果），减少实时计算压力，比如提前打印常用报表，避免每次查询都重新计算。这样组合起来，能有效提升复杂查询性能。
6) 【追问清单】
- 关于索引选择，为什么选择联合索引而非多单字段索引？
- 答：联合索引能一次性定位多条件，避免多单索引的查询合并开销，且查询效率更高。
- 分库分表时，如何处理跨分片（分库/分表）的关联查询？
- 答：通过分片键（如doctor_id）保证关联一致性，或使用分布式事务（如两阶段提交）保证数据一致性。
- 缓存策略如何设计？如何避免缓存雪崩？
- 答：采用分布式缓存（如Redis），设置过期时间，热点数据不过期，并实现缓存预热和失效通知机制。
- 数据一致性如何保障？
- 答：采用分布式事务（如两阶段提交）或最终一致性（如事件溯源），确保跨分片数据一致性。
- 扩展性如何考虑？
- 答：分库分表策略支持按医生ID或时间范围动态扩展，索引设计支持新增字段扩展，缓存支持水平扩展。
7) 【常见坑/雷区】
- 只建单字段索引：未考虑多条件查询，导致查询效率低。
- 分库分表策略不当：未考虑关联查询，导致跨分片查询性能差。
- 未考虑数据一致性：分库分表后未处理事务一致性，导致数据不一致。
- 缓存未考虑热点数据：缓存策略不合理，导致缓存命中率低。
- 索引字段顺序错误：未按查询频率排序，导致索引失效。