王继伟：信创背景下，医院数据库如何实现集约化管理？| 2025年南湖HIT论坛

来源：HIT专家网      作者：龚晨

“少就是多。在医疗信创中，医院信息部门不要盲目增设数据库实例，应基于业务峰值，评估数据库性能需求，再根据业务域规划实例数量，通过集约化管理，降低异构数据库管理压力。”

近日，在HIT专家网主办的以“价值导向，前瞻‘十五五’”为主题的2025年南湖HIT论坛上，厦门大学附属成功医院信息科主任王继伟分享了医院数据库集约化管理与信创实践。

“我国中小医院占比很高，800张以下床位的医院数量占比超过93%。不论是信息技术队伍还是信息化投入，中小医院与大医院均没有可比性。因此，针对中小医院开展数据库集约化管理，尤为必要。”

医院数据库的管理现状

王继伟首先分析了当前医院数据库管理中存在的主要问题。

首先是数据库实例冗余，导致管理负荷剧增。大医院的数据库实例经常达到50-60个，小型医院也有近十个。数据库实例数量过多，消耗医院信息部门大量精力，难以聚焦核心业务支撑。

其次是数据库管理的复杂度超出运维能力。过多的实例配置，使得医院信息部门对数据库的精细化管控能力不足，日常管理多停留在基础维护，无法实现数据库的高效优化。

在这两者的共同作用下，医院信息部门的“技术空心化”问题凸显：难以掌握数据库核心技术，关键操作依赖外部支持，自主解决问题能力弱，已形成管理被动的局面。

“特别是在信创环境下，旧问题叠加，新挑战凸显，这种风险正在持续升级。”王继伟认为，一方面，医院应用国产数据库后，未对原有实例进行整合，仍延续“多实例”管理模式，导致历史问题持续存在。另一方面，此前医院以Oracle、SQL Server、MySQL等数据库为主，可选择的数据库厂商少，总体学习成本相对较低，如今国产数据库厂商选择更加多样，且各厂商的技术栈差异大，医院信息部门的学习成本与管理难度大幅提升。

“国产数据库厂商技术栈的门槛较高，医院的技术承接能力不足，对外部支持的依赖度更高，自主管理能力被进一步削弱。在信创阶段，这可能会使得医院信息部门的技术空心化程度较之前更为严重。”王继伟说。

基于医院业务峰值的数据库集约化管理方案

当前，医疗信创对数据库的最大疑虑是“性能能否扛得住”。王继伟认为：首先，医院存在明显的业务高峰期，如上午9-11点是门诊高峰，如果这个时段能撑住，那数据库的性能就没问题；其次，医院规模差异较大，800张以上床位的医院数量占比不到7%，不同规模医院对数据库的性能要求也存在明显差异，不能一以概之。

基于上述观察与实践经验，王继伟建议：应将“医院业务峰值”作为数据库性能设计的核心锚点。“医院业务峰值”很难量化，而“日门诊量峰值”和“住院患者占床峰值”这两个能够量化的指标通常与“医院业务峰值”正相关，因此可以将“医院业务峰值”转化为医院的“日门诊量峰值”和“住院患者占床峰值”进行量化测算。随后，以业务峰值为临界值，划分医院规模，设计“医院数据库集约化管理方案”，为不同类型的医院提供适配不同数量的数据库实例。

该方案的核心目标，是在保障业务峰值性能的前提下，最小化独立数据库的实例数量，平衡性能保障、管理效率与自主运维能力。

王继伟进一步介绍了不同业务峰值医院的数据库管理方案。

第一类是“低业务峰值医院”。低业务峰值医院是指日门诊量峰值小于3000人次、住院占床患者峰值小于800人的医院，其业务峰值量较小，数据交互并发需求一般，无极端性能压力。在该方案中，只需设置1个业务数据库实例，并将所有医疗业务系统集中于此。其优势在于，医院信息团队仅需掌握一种数据库技术，即可实现日常自主运维，管理成本最低。

第二类是“中业务峰值医院”。中业务峰值医院是指日门诊量峰值在3000-5000人次之间、住院占床患者量峰值在800-1200人的医院，其业务峰值量适中，有一定的数据交互并发需求，对数据库性能有较高要求。可设置2-3个业务数据库实例的方案，分别安排给医疗业务系统、运营管理或其他联机分析处理（OLAP）系统等。医院信息团队需掌握一种、最多两种数据库技术，可实现日常自主运维，管理成本适中。

第三类是“高业务峰值医院”。高业务峰值医院是指日门诊量峰值大于5000人次、住院占床患者峰值大于1200人的医院，其峰值业务数据量大、并发高，需优先保障核心系统稳定运行。可设置4-6个业务数据库实例的方案，分别安排给医院基础信息系统（电子病历、患者管理、计价收费）、其他临床信息系统、运营管理信息系统及其他联机分析处理（OLAP）或集成平台等。这种方案的优势在于，既能通过分域隔离以保障性能，又避免实例过多导致的管理难度，医院信息团队聚焦于2-3种数据库技术即可，易建立自主能力。

不同业务峰值的数据库管理方案，其管理实施路径也有所不同。王继伟认为，最佳时机是在开展信创改造而进行的系统升级时，既完成了信创工作，又实现了数据库集约化管理。

建议中低业务峰值医院要做好如下工作：

（1）峰值性能评估：模拟历史业务峰值场景，测试目标国产数据库实例的并发承载与数据处理能力，确保满足未来1-2年医院业务峰值增长需求。

（2）系统整合：梳理所有业务系统的数据结构，统一数据标准与交互规则，消除系统间的数据冲突。

（3）分批次迁移：优先迁移低并发、非核心系统，验证稳定后再迁移核心系统，降低迁移风险。

（4）自主运维能力建设：针对1-2个实例开展全员技术培训，建立峰值时段的专项监控、备份与故障应急流程，实现自主运维。

而高业务峰值医院则要做好如下工作：

（1）峰值业务域梳理：分析各业务系统在峰值时段的负载特征，明确几个实例的业务边界与数据交互频率，避免跨域频繁调用加剧性能压力。

（2）厂商选型优化：优先选择2-3家技术成熟的国产厂商，为需求不同的数据库实例匹配合适的数据库，尽量减少厂商数量，降低管理复杂度。

（3）峰值性能测试、优化及分批迁移：模拟极端峰值场景，测试各实例负载能力，通过扩容资源、优化索引、调整缓存策略等方式提升峰值性能。测试优化后，优先迁移低并发系统，再迁移核心系统。

（4）运维能力共建：针对选定的数据库开展专项技术培训，同时与厂商签订“辅助式”技术支持协议（非全包），逐步从“依赖外部”转向“自主主导”，规避技术空心化。

厦门大学附属成功医院的“双实例”实践

上述方案的设计思路，来源于厦门大学附属成功医院的自身实践经验。

2023年12月8日，厦门大学附属成功医院将包括HIS在内的全部业务系统正式切换到“全栈国产平台”并实现“全场景应用”，率先实现“三甲医院全面信创”。在数据库方面，医院实现从Oracle数据库向达梦数据库的平稳适配和迁移。

王继伟介绍，由于厦门大学附属成功医院的日门诊量峰值在3000-5000人次、住院占床患者量峰值在800-1200人之间，属于中等业务峰值医院。在信创实践前，医院已将绝大部分业务系统集中在一个被称为泛HIS的Oracle数据库实例中。在信创实践时，临时将电子病历、手术麻醉等系统与原泛HIS数据库分离，从原来一个实例改为两个实例，并分别迁移至两个达梦数据库实例中，即电子病历类数据库和泛HIS数据库，相当于选择了业务数据库“双实例”的过渡方案。

经过超过半年的运行观察，医院信息部门发现：业务关联紧密的系统进行跨库交换数据时，较之前的单实例效率要低一些，为此于2024年6月将电子病历类数据库中的电子病历、手术麻醉等系统再回迁至泛HIS的达梦数据库中，原电子病历类数据库只暂时保留医学影像系统（现被称为医学影像数据库）。因此，医院在用的102款业务软件，除影像系统留在医学影像数据库外，其他业务系统均设置在泛HIS类数据库中。

从2023年12月至今，医院的业务数据库“双实例”方案从“泛HIS、电子病历类”演变为“泛HIS、医学影像类”。“双实例”方案已连续稳定承载医院业务23个月，验证了中低峰值医院采用较少数据库实例的可行性。

不仅如此，由于医学影像类数据库主要管理影像数据的索引，其数据库的性能压力并不大，后续将该医学影像系统迁移至泛HIS数据库实例中，也是可行的。

同时，较业务类数据库相比，医院的行政办公类数据库基本不存在性能压力，当前均设置在一个泛办公类数据库的实例中。事实证明，医院设置一个泛办公类数据库实例，同样可行。

王继伟认为：以日门诊量、住院占床患者数量等业务峰值为标准，划分医院规模，匹配数量有限的数据库实例方案，是信创环境下平衡峰值性能、管理成本自主能力的可行路径。未来，结合信创云技术，将单/多实例部署于云平台，利用云资源弹性扩展能力，更灵活地应对业务峰值波动，可进一步提升数据库管理的高效性与稳定性。

【演讲视频】

【课件下载】

【责任编辑：陈曦 版式：明超】