本站原创优化前后的调用表顺序
在数字化医院建设的大潮中,某医院信息中心与某公司合作开发了门诊医生站,于2008年1月初试运行,并新增50台计算机和一台新的怎么写作器.门诊医生站项目从筹划到上线一直很顺利,却没有想到竟然出现了查询速度慢的问题.这是为什么呢该医院信息中心作了原因的分析.
速度变慢原因逐个排查
该院信息中心在做门诊医生站的需求分析时,就明确了必须满足和预交金两种费用结算模式的需要,给病人以选择权.在预交金结算费用方式下,病人在预交一定后,就无需排队挂号交费,诊疗时医生在电脑上刷卡后即完成挂号费用的交纳,问诊开药后可直接在电脑上刷卡交费,免去以往划价、缴费时楼上楼下跑以及排长龙的麻烦.
在预交金结算模式下,门诊挂号和收费处都要从系统里调出病人的历史信息,他们普遍反映刷卡查找病人时非常慢,在星期一及星期六上午病人较多时尤其如此.而对结算模式的病人,门诊挂号和收费时并没有出现速度变慢的状态.
结合多年的实践,该院信息中心认为,系统性能的下降可能有这几方面的原因：一是硬件性能不够；二是数据库的相关参数设置不当,影响了系统性能；三是SQL语句设计方面的原因.
对于这几方面的原因,该院信息中心首先排除了前两个原因.在建设门诊医生站时,该院信息中心购写了新的怎么写作器,远远没有达到充分利用的水平.对于数据库参数的设置,该院信息中心在以前已经做过比较充分的调整,本次系统性能的恶化基本也可以排除这一原因.
由于速度变慢主要表现在刷卡查找病人这个环节,该院信息中心决定重点分析SQL语句方面的原因.该院信息中心发现,在刷卡定位病人时,需用到5个表,即就诊主记录、科室字典、病人主索引、门诊就诊队列和合同单位字典,且调用表的顺序是就诊主记录、科室字典、病人主索引、门诊就诊序列、合同单位字典.
很明显,调用表的顺序可以优化,常规记录数基本固定的小表应放在最前面,如科室字典、合同单位放在前面,大表如就诊主记录、病人主索引和门诊就诊队列应放在后面.因为在刷卡查找病人时,最先找到的是ID,而病人索引表中病人ID是主索引.因此该院信息中心认为,在查找病人的SQL语句中,如果WHERE语句先对ID赋值,再从病人索引中查找病人的基本信息,其效率应该最高.
在同一时间段,门诊挂号、收费处和医生均要对就诊病人进行刷卡查询.如果系统未能优化,必将导致系统性能的下降,自然会影响对实时性要求很高的环节,如挂号、收费和门诊,这也能很好地解释当时挂号和收费处操作人员反映的问题.
调用表顺序优化
根据前面的分析,该院信息中心对SQL语句进行了调整,即将科室字典、合同单位放在前面,将就诊主记录、病人主索引和门诊就诊队列放在后面.在其他条件不变的情况下,该院信息中心统计了SQL语句的执行时间,其查询速度提高了19%,而就诊主记录、病人主索引和门诊就诊队列3个表的顺序安排,对测试几乎没有影响.如果同时将WHERE后的SQL语句改为先对ID赋值,从病人索引中查找病人的基本信息,再关联其它表,这时查询病人的速度又可提高12%.
对门诊就诊队列,该院信息中心根据医院挂号保留的天数进行数据处理.正常情况下,其过期的数据没有保留的意义,可以做合适的处理,如转储.实测结果是,在不对门诊就诊队列表作任何处理和只保留2天记录的情况下,后者查询速度比前者提高了约21%.
对SQL语句进行调整和相关表记录进行处理,就使系统性能提高了很多,这不得不引起数据库管理和编程人员的极大重视.
随着系统应用的继续,就诊主记录会不断增加,因此应根据医院的查询要求,保留必要的数据,其他记录应及时进行转储.其原因是,对数据库进行写操作时,速度与被写表记录的大小基本没有关系；而对数据库进行读操作时,定位记录与被读表记录的大小关系很大.及时对大表进行转储,是提高读操作一个有效的办法.