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