早上八点，门诊刚开诊，系统就”抽风”了。

不是全面崩溃，而是”间歇性失能”——挂号时好时坏，有时能挂上，有时直接报”系统繁忙”；收费窗口收不了费，反复提示”连接超时”；药房系统频繁掉线，药剂师急得直拍桌子。

更诡异的是，这种现象没有规律——可能连续十笔都正常，第十一笔就挂掉；可能某个窗口一直正常，换个窗口就出问题。重启服务，暂时恢复，但半小时后又开始”抽风”。

1. 从日志中发现蛛丝马迹

李主任带着团队排查了半天，CPU、内存、磁盘、网络都正常，数据库监控也”一片绿色”。但故障就是真真切切地发生了，患者投诉电话不断，门诊科主任亲自跑来质问：”什么时候能搞定？我们患者都堵成马了！”

老林建议从日志入手。他们调出了过去两小时的应用日志和数据库日志，开始逐条分析。小吴发现了一个模式：每次故障发生前，数据库中都会出现一批持续时间很长的查询语句，执行时间从30秒到3分钟不等，内容都是关于”门诊挂号统计”的某个特定查询。

“这个查询不应该这么慢，”小吴说，”它走的索引是合理的。”

但当他仔细查看这些慢查询的执行计划时，发现了一个细节：它们在某个表上做了全表扫描，而那个表应该有索引。再往下追查，发现那个索引在昨天晚上被不小心删除了——部署一个补丁时，多执行了一个DROP INDEX语句，而 nobody 注意到。

“重建索引，”老林说，”应该能立刻解决问题。”

但问题没那么简单。索引重建后，系统确实快了几分钟，但间歇性故障又出现了。看来，那个dropped索引只是表象，不是根因。

2. 报表任务变成了定时炸弹

小吴继续深挖日志。他发现，每次故障窗口，数据库的锁等待数量都会激增。具体来说，是很多会话在等待一个名为”IX”的锁——表级意向锁。这说明，有大量事务在等待获取某个表的锁。

“是什么事务在持有锁？”李主任问。

小吴筛选出锁持有最长的会话，发现它们都在执行同一个存储过程：usp_GenerateDailyReport，每天门诊结束后自动运行的报表生成。这个报表需要统计当天的挂号、收费、药房数据，涉及多张大表的联合查询。

“但它应该是在晚上十点后才运行，”李主任说，”为什么现在早上八点也在跑？”

原来，由于昨晚报表生成时间过长（因为索引问题），到了午夜十二点还没完成。系统设计有重试机制，每隔一小时再次尝试。于是，早上八点时，第四个重试正在执行，而且因为数据量累积，执行时间更长。

他们做了两个动作：

1. 立即终止正在运行的报表任务

2. 临时禁用重试机制，防止再次触发

故障立刻缓解。但李主任知道，这只是治标不治本——如果报表任务依然需要跑这么久，晚高峰时它再次重试，问题会重现。

真正的解决需要优化报表本身。老林带着团队分析了这个报表的SQL，发现它有很多不必要的DISTINCT和子查询，而且没有分页机制，一次性拉取了全量数据。他们重写了这个报表的查询逻辑，增加了分阶段汇总，将执行时间从原来的25分钟降到了3分钟。

3. 资源争用：看不见的瓶颈

但李主任还提出了一个管理上的问题：”为什么一个报表的异常，会拖垮整个门诊系统？”

答案在于数据库资源的”独占”问题。那个报表任务运行在一个独立的数据库连接上，但它使用了大量内存排序和临时表，占用了大量共享资源。而门诊业务的高频查询，恰恰也需要这些资源。两者发生了资源竞争。

“我们应该给报表任务设置资源限制，”李主任说，”或者在非高峰时段运行。”

团队最终决定：

1. 报表任务改到晚上十一点到次日凌晨四点之间运行，避开业务高峰

2. 为报表任务单独配置一个数据库连接池，限制其最大连接数

3. 增加报表执行时间的监控，超过10分钟自动告警

争议最大的是第三个决定。老林担心：”万一报表真的需要跑更长时间怎么办？”

李主任回答：”那就得有人来评估，是否需要调整业务逻辑。不能让它无声无息地占着资源，把门诊拖垮。”

4. 故障之后的教训

故障解决后的第三天，李主任在科室内部做了一个分享。他总结道：

“这次故障，表面上是一个SQL性能问题，根子是资源争用与任务调度的配合失误。我们系统里有很多定时任务——报表、对账、数据同步——如果它们的执行时机和资源消耗没有管控，就可能在不该出现的时候抢占业务资源。”

“更根本的是，我们的监控体系有盲区。我们只监控了’系统是否活着’、’CPU是否爆了’，但没有监控’资源竞争程度’。锁等待数、临时表增长、内存排序量，这些才是真正预示问题的指标。”

一周后，团队上线了一套新的数据库运营看板，专门监控这些”隐形指标”。李主任把这次故障的经过和分析写成了案例，发给了全院信息科。

三个月后，当软佳的客户成功经理来医院进行数据安全审计时，李主任主动提起了这次故障。他说：”我们后来复盘，发现最危险的不是故障本身，而是故障发生前的’正常假象’——所有监控指标都是绿的，但业务已经不正常了。”

“所以现在，我们新增了一个’业务感知监控’——每隔十分钟，自动模拟一次挂号操作，测量响应时间。如果响应时间超过2秒，即使其他指标正常，也触发告警。”

客户成功经理点头：”这是正确的方向。运维的核心价值，不是保证系统’不挂’，而是保证业务’不卡’。”

李主任笑了笑：”而这次故障，让我们明白了’卡’从哪里来。”

互动话题

你们医院遇到过”监控正常但业务异常”的情况吗？是怎么发现并解决的？你觉得最应该监控哪些”非传统”指标来预防这类问题？欢迎在评论区交流你们的运维心得。

> 基于真实医院场景改编，人物均为化名

立即免费试用门诊系统：https://app.kmhis.com/
International Version：https://app.kmhis.com/multi/
了解软佳门诊管理系统详情：https://www.kmhis.com/outpatient-management-system.html

手机扫码试用患者预约。请勿输入个人真实信息（点击图片可查看原图）

支持8种语言：简体中文、繁体中文、香港中文、English、藏文、泰文、老挝语、越南语

说真的。这类问题我见过太多了。每次看到医院同事为选型头疼。我就想，要是早点有人把这些经验分享出来就好了。毕竟。选择不对。后面全是麻烦。选择对了。省心省力。还能提升整个机构的运行效率。希望这篇能帮到正在纠结的你。

你如果有具体需求。也可以去 www.kmhis.com 看看。那里有更详细的技术方案和案例。