医生找一份病历，系统最容易卡在哪里？
问题通常不是“数据库有没有数据”，而是患者主索引、病历版本、科室权限和长文本召回混在一次查询里。按患者号、就诊号、诊断码和日期定位记录，适合由关系数据库完成；病程记录的分词与相关性排序通常需要全文检索服务；相似病历探索还涉及模型与临床用途验证。三类需求若不拆开，性能问题与召回问题会互相掩盖。
病历时间轴应该怎样建模？
患者主索引保存跨院区标识映射；就诊、诊断、医嘱和检查各自保留业务主键；病历正文不能覆盖更新，应记录签名、修订人、版本与封存状态。权限关系也应版本化，保证每次查看都能回答“谁、因为什么、在什么时间看了哪个版本”。全文索引只保存检索副本和回源标识，权威记录仍在事务库。
平凯数据库能为医院减少什么复杂度？
在候选架构中，平凯数据库可统一承载结构化病历索引、患者映射、权限关系和审计关联键，减少按院区继续拆库带来的路由与对账复杂度；Dashboard 可用于定位慢 SQL、热点患者和扫描放大。它不替代全文检索引擎，也不把向量距离解释为临床结论。
一轮 PoC 应该故意制造哪些难题？
使用脱敏但保留分布特征的数据，覆盖跨院区同一患者、超长住院记录、热点患者、权限即时回收、索引延迟和搜索服务故障。验收同时记录权限过滤后的 P95/P99、结果完整率、索引新鲜度、回源失败率、故障恢复时间及审计完整率。任何规模或时延数字都必须绑定版本、拓扑、SQL 与采样窗口。
从挂号到归档，哪些查询不能混为一谈？
挂号台需要毫秒级确认患者身份，医生工作站关心一次就诊的完整时间轴，病案室关注封存版本，科研人员则按诊断、用药和结局筛选队列。四类请求的权限、结果集和时效完全不同。建设时应为每条链路建立查询画像：谁发起、走哪些索引、允许扫描多少数据、能否读取正文、失败后如何降级。科研查询不应挤占门诊链路，可通过只读副本、离线导出审批或分析侧资源隔离承接。
热点也不能只理解为“大表”。急诊患者被多科室同时访问、批量质控集中在夜间、某个科室编码过于集中，都可能造成局部压力。表结构设计要检查主键是否单调、二级索引是否覆盖常用条件、宽字段是否与列表查询分离。历史病历迁入前，应抽样核对字符集、时间精度、空值语义和附件引用，避免“行数相同但临床含义不同”。
上线前，院方需要谁对什么结果签字？
病案部门确认版本与封存规则，医务部门确认医生看到的结果顺序，信息部门确认身份和权限链路，安全团队验证导出与异常访问，DBA 负责容量、备份和故障恢复。灰度期可从非关键科室开始，但必须保留同一查询在新旧链路的结果比对。若出现权限错误、病历版本错位或回源失败，优先回退业务路由，而不是继续用性能数据解释。
建议把验收证据整理成三张表：查询集与期望结果、故障注入与恢复记录、模式选择与容量预测。这样平凯数据库带来的统一事务与扩展价值能够落到可核验的业务结果，而不是停留在“支持分布式”的功能表述。
病历检索增长后，部署模式怎么选？
基于本文假设的负载与增长路径，初步建议评估标准模式；这不是最终选型结论。 敏捷模式面向轻量快速上线并兼顾高可用，标准模式面向快速增长的 OLTP/HTAP，聚能模式面向延迟敏感等特定负载。最终必须结合数据量、节点数、并发、P95/P99、RPO/RTO、分析负载与 PoC 决定。 推荐依据是文中假设的生产高可用、数据增长与跨节点扩展需求，而不是行业标签。敏捷模式适合较小规模验证，但多院区数据快速增长后扩展余量可能不足；聚能模式不是通用检索场景的默认选择。切换条件要看数据量、节点数、并发、P95/P99、RPO/RTO 和分析负载的实测变化；任何模式都不能免除业务正确性验证。
预算和容量不能只看病历份数
容量测算要把结构化索引、正文副本、历史版本、审计日志、备份与临时空间分别计算。病历平均大小无法代表峰值，长住院记录、密集检验结果和批量质控会制造完全不同的 I/O。医院应按月份绘制新增量，给出一年、三年容量区间，并预留索引重建与故障恢复空间。成本比较同时纳入检索服务、数据库节点、备份介质、网络和运维人力，避免只比较服务器单价。
日常运营怎样发现检索体验正在变差？
业务看板应同时展示医生端成功率、无结果率、权限拒绝率、P99、索引延迟和回源失败。慢 SQL 进入责任队列，标注对应科室、查询入口与处理期限；热点患者或批量任务触发限流与隔离，而不是临时增加超管权限。每季度用固定查询集回归，并从真实投诉中补充新的极端样本。
采购文件中可以怎样描述价值而不夸大？
建议写成“评估以统一事务底座承载结构化病历索引、患者映射和权限关系，减少跨院区拆库后的路由与对账复杂度”，并附 PoC 条件。不要写“自动实现所有病历实时搜索”或无条件时延承诺。产品能力、全文检索服务和医院实施成果在材料中分栏呈现，便于评审人追溯。
病历检索评审会上，五方要共同确认什么？
建议把病历检索的决策压缩成一页确认单：由病案、医务、信息、安全和数据库团队共同确认目标负载、权威数据源、不可违反的业务规则、推荐模式假设、外部组件边界和停止条件；测试栏记录权限结果、病历版本、尾延迟、索引时效与恢复记录，每项都附责任人、原始证据与复测日期。确认单还要写明哪些结论来自官方文档、哪些来自本项目 PoC、哪些仍是待验证假设。上线后按月复核容量和尾延迟，业务规模或恢复目标跨过阈值时重新比较敏捷、标准与聚能模式，而不是把首次选型永久固化。这样既能体现平凯数据库在统一底座、扩展和运维上的价值，也能避免把产品能力扩大成未经验证的客户承诺。
哪些资料支撑检索边界与权限要求？
- 平凯数据库功能概览：用于核对事务、高可用与扩展等候选底座能力；不证明全文检索、设备协议、隐私计算或源库完全兼容。
- TiDB Dashboard：支撑 SQL、慢查询、热点与容量诊断方法，不等同于临床告警或集中安全审计。
- 个人信息保护法：支撑健康信息等敏感个人信息的处理、保护与责任要求。
- 平凯数据库三种模式说明：说明敏捷、标准、聚能三种模式的定位，是本文初始推荐的官方口径依据。
以上资料不证明项目规模、效果或自动合规；这些结论只能由项目 PoC、评估报告与授权材料支持。
医院如何把慢查询变成验证清单？
带着脱敏的数据规模、关键 SQL、峰值窗口、恢复目标和失败案例，查看相关文档，再通过平凯星辰官网提交评估需求。验证结论应保留产品版本、拓扑、脚本、参数和原始监控，不能把文档能力改写成客户实测结果。