本文就怎么优化大型数据库的功用进行了一些探究，提出了优化数据库拜访功用的若干战略，特别是对SQL句子进行了有用的剖析规划的问题，以使其加速履行速度，削减网络传输，能更高效地作业，充分发挥体系的功率。
跟着医院信息体系模块的不断添加，特别是近两年电子病历的运用，临床治疗信息许多写入数据库，数据量急剧添加，形成事务数据库十分巨大，事务处理的速度显着下降。依据这一问题，本文就怎么优化大型数据库的功用进行了一些探究，提出了优化数据库拜访功用的若干战略，特别是对SQL句子进行了有用的剖析规划的问题，以使其加速履行速度，削减网络传输，能更高效地作业，充分发挥体系的功率。
医院通过多年的信息化建造，取得了显着成效，信息化由本来的以收费、记帐为主，逐渐向临床医疗、服务患者过渡。跟着医院信息体系模块的不断添加，特别是近两年电子病历的运用，临床治疗信息许多写入数据库，数据量急剧添加，形成事务数据库十分巨大，事务处理的速度显着下降。加之在频频的事务数据库中还要进行大数据量查询或报表核算，导致在事务处理时常常呈现堵塞或死锁现象，严峻影响到日常的作业。故怎么对数据库功用在进行优化规划，即进步数据库的吞吐量、削减用户等待时刻具有重大含义。
传统的数据库功用优化首要从操作体系、客户端运用软件程序规划、网络及其它硬件设备等方面来考虑，这种办法仅仅调整数据库的周边环境，只能暂时缓解问题，而不能从根本上解决问题。实践运用中，更多状况是医院信息体系(包含数据库体系)都已规划好，仅仅在运转的进程中跟着数据规划的增大，使得体系呈现周期性功用问题。本文提出的医院数据库体系功用优化是在己有的硬件设备晋级、数据库的物理规划、联系规范化等方面进行改善根底之上，对SQL句子进行了有用的剖析规划的问题，以使其加速履行速度，削减网络传输，能更高效地作业，充分发挥体系的功率。
1 合理运用索引
进步数据库查询速度最有用的办法便是优化索引。索引是树立在实体表上的一种数据安排，它能够进步拜访表中一条或多条记载的查询功率，运用索引的意图是为了防止全表扫描，削减磁盘I/O的次数，加速查询速度，在大型的表中进行索引的树立对加速表的查询有着重要的含义。可是也并不对任何的数据表都要树立索引，索引一般能进步select、update以及delete句子的功用（当拜访的行较少时），但会下降insert句子的功用（因为需求一起对表和索引进行刺进）。此外，过多的索引会产生保护上的开支，只会下降而不是添加体系的功用，索引的运用要适可而止。索引运用准则如下：
（1）在常常进行衔接，可是没有指定为外键的列上树立索引，而不常常衔接的字段则由优化器主动生成索引。
（2）在频频进行排序或分组（即进行group by或order by操作）的列上树立索引，而频频进行删去、刺进操作的表不要树立过多的索引。
（3）在条件表达式中常常用到的不同值较多的列上树立检索，在不同值少的列上不要树立索引。比如在雇员表的“性别”列上只要“男”与“女”两个不同值，因而就没有必要树立索引，假如在此树立索引不光不会进步查询功率，反而会严峻下降更新速度。
（4）假如待排序的列有多个，能够在这些列上树立复合索引（compound index）。尽量运用较窄的索引, 这样数据页每页上能因寄存较多的索引行而削减操作。
（5）在查询中常常作为条件表达式而且不同值较多的列上树立索引，而不同值较少的列上不要树立索引。
（6）当数据库表更新大数据后, 删去偏从头树立索引来进步查询速度。
总归，树立索引必定要稳重，对每个索引树立的必要性都要仔细剖析，必定要有树立的依据。过多的索引或不充分、不正确的索引对进步数据库的功用毫无好处。
2 SQL句子优化
SQL言语是一种十分灵敏的言语，相同功用的完结常能够用几种不同的句子来表达，但句子的履行功率或许存在很的不同。因而，任何一个数据库运用体系中，合理的对SQL句子进行优化将大大的进步整个数据库体系的功用。一切的SQL句子履行进程分三个阶段，别离是进行处理语法剖析、履行、读取数据。
图1 SQL句子履行进程
在运用SQL时，功用差异在大型的或是杂乱的数据库环境中，如在HIS的一些大型表中体现尤为显着。通过一段时刻的总结，发现SQL句子比较低下的原因首要来自于不恰当的索引规划、不充分的衔接条件和不行优化的WHERE子句及其它不恰当的句子操作等，在对它们进行恰当的优化后，其运转速度有了显着进步。下面将从这几个方面别离进行阐明：
2.1 LIKE操作符
LIKE操作符能够运用通配符查询，里边的通配符组合或许到达几乎是恣意的查询，可是假如用得欠好则会产生功用上的问题，如like ‘a%’ 运用索引，like ‘%a’ 不运用索引。用 like ‘%a%’ 查询时，查询耗时和字段值总长度成正比，所以不能用CHAR类型，而是VARCHAR。
2.2 约束回来行
在查询Select句子顶用Where字句约束回来的行数，防止表扫描，假如回来不必要的数据，浪费了服务器的I/O资源，加剧了网络的担负下降功用。假如表很大，在表扫描的期间将表锁住，制止其他的联接拜访表，后果严峻。能够运用TOP句子来约束回来成果。当回来多行数据时，尽或许不运用光标，因为它占用许多的资源，应该运用datastore。
2.3 UNION操作符
UNION在进行表链接后会挑选掉重复的记载，所以在表链接后会对所产生的成果集进行排序运算，删去重复的记载再回来成果。实践大部分运用中是不会产生重复的记载，最常见的是进程表与前史表UNION。引荐选用UNION ALL操作符代替UNION，因为UNION ALL操作仅仅简略的将两个成果兼并后就回来。
2.4 Between与IN
Between在某些时分比IN速度更快，Between能够更快地依据索引找到规模。如：
select * from YF_KCMX where YPXH in (12,13)
Select * from YF_KCMX where between 12 and 13
一般在GROUP BY 个HAVING字句之前就能除掉剩余的行，所以尽量不要用它们来做除掉行的作业。他们的履行次序应该如下最优：select 的Where字句挑选一切适宜的行，Group By用来分组个核算行，Having字句用来除掉剩余的分组。这样Group By 个Having的开支小，查询快。关于大的数据行进行分组和Having十分耗费资源。假如Group BY的意图不包含核算，仅仅分组，那么用Distinct更快。
2.5 留意细节
一般不要用如下的字句: “＜＞”, “!=”, “!＞”, “!＜”, “NOT”, “NOT EXISTS”, “NOT IN”, “NOT LIKE”, and “LIKE ‘%500’”，因为他们不走索引满是表扫描。NOT IN会屡次扫描表，运用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 来代替，特别是左衔接,而Exists比IN更快，最慢的是NOT操作.假如列的值含有空，曾经它的索引不起作用， “＜＞”, “!=”, “!＞”,等仍是不能优化，用不到索引。
不要在WHere字句中的列名加函数，如Convert，substring等,假如有必要用函数的时分，创立核算列再创立索引来代替。还能够变通写法：
WHERE SUBSTRING(firstname,1,1) = ‘m’
改为：WHERE firstname like ‘m%’（索引扫描）,但MIN() 和 MAX()能运用到适宜的索引。
select * form ZY_FYMX where FYDJ ＞ 3000
剖析在此句子中若FYDJ是Float类型的，则优化器对其进行优化为Convert(float,3000)，因为3000是个整数，咱们应在编程时运用3000.0而不要等运转时让DBMS进行转化。相同字符和整型数据的转化。应改为：
select * form ZY_FYMX where FYDJ ＞ 3000.00
2.6 防止相关子查询
一个列的标签一起在主查询和where子句中的查询中呈现，那么很或许当主查询中的列值改动之后，子查询有必要从头查询一次。查询嵌套层次越多，功率越低，因而应当尽量防止子查询。假如子查询不行防止，那么要在子查询中过滤掉尽或许多的行。
3 SQL事例剖析
3.1事例剖析一
医院数据库容量为28GB，依据对MS_CF01和MS_CF02的巨细核算，其间MS_CF02记载条数为1000万条；发药核算时刻一个月，耗时30分钟依然无法得到成果，严峻影响正常事务，遂间断。
原先核算的SQL句子如下：
select sum(MS_CF02.YPSL*MS_CF02.YPDJ*MS_CF02.CFTS) as total
from MS_CF01,MS_CF02
where MS_CF01.CFSB=MS_CF02.CFSB and MS_CF01.CFLX=1
and (MS_CF01.FYBZ=1 or MS_CF01.FYBZ=3)
and MS_CF01.FYRQ＞=”2004.3.1 00:00:00”
and MS_CF01.FYRQ＜=”2004.3.30 00:00:00”
and MS_CF01.ZFPB=0
依据对体系的剖析(仅限于MS SQL Server数据库)，给出相应的优化方案，能够在功用上大幅度进步：
select top 1CFSB from MS_CF01 where FYRQ＞=”2004.3.1 00:00:00”
//得到该时刻段内最小的CFSB,例如3198724
select top 1CFSB from MS_CF01 where FYRQ＜=”2004.3.30 00:00:00”
order by CFSB desc //得到该时刻段内最大的CFSB，例为4178763
select sum(MS_CF02.YPSL*MS_CF02.YPDJ*MS_CF02.CFTS) as total
from MS_CF01,MS_CF02
where MS_CF01.CFSB=MS_CF02.CFSB and MS_CF01.CFLX=1
and MS_CF02.CFSB＞=3198724 and MS_CF02.CFSB＜=4178763
and (MS_CF01.FYBZ=1 or MS_CF01.FYBZ=3)
and MS_CF01.ZFPB=0
一切句子履行结束后，成果不超越18秒。
3.2事例剖析二
医院作业人员反映在药库体系主动方案模块履行速度很慢，有时大约需求半个小时才干跳出窗口。
通过剖析发现,在w_yk_plan.cb_auto.clicked() 18行开端的代码如下：
ls_select+= select YK_TYPK.YPXH,YPMC,YPGG,YPDW,GCSL,DCSL,0
ls_select+= from YK_TYPK,YK_KCMX
ls_select+= where XTSB=+string(base_info.syscode)+ and DCSL＞0 and GCSL＞DCSL and YKZF=0
ls_select+= and YK_TYPK.YPXH not in (select YPXH from YK_KCMX)
ls_select+= group by YK_TYPK.YPXH,YPMC,YPGG,YPDW,GCSL,DCSL
明显是NOT IN句子导致速度很慢,然后把该句子改成:
ls_select+= select YK_TYPK.YPXH,YPMC,YPGG,YPDW,GCSL,DCSL,0
ls_select+= from YK_TYPK
ls_select+= where XTSB=+string(base_info.syscode)+ and DCSL＞0 and GCSL＞DCSL and YKZF=0
ls_select+= and not exists ( select YPXH FROM YK_KCMX WHERE YK_TYPK.YPXH = YK_KCMX.YPXH )
ls_select+= group by YK_TYPK.YPXH,YPMC,YPGG,YPDW,GCSL,DCSL “
成果5秒内履行完结。
3.3事例剖析三
以下SQL的功用是医院用于作日报时显现哪些收费员还没有做过当天的个人日报，速度十分慢，每次都需求好几分钟才干出来数据。
明显这个问题是因为不合理的子查询形成的，经剖析后咱们把子查询从where子句中去除，句子改成如下后，2秒内数据库出来了。
某些HIS体系中病区体系中医嘱提交、医嘱履行、医技提交速度慢问题原因剖析ZY_BQYZ 这个表中出院数据没有转出到ZY_BQYZ_CY 表中。
没有树立正确的索引，SQL 句子自身存在的问题，在医嘱提交中的WHERE子句：
WHERE ( ZY_BQYZ.ZYH = ZY_BRRY.ZYH AND ZY_BRRY.CYPB = 0 )
AND ( ZY_BQYZ.SRKS = :al_hsql)
AND ( ZY_BQYZ.LSBZ=0 OR ZY_BQYZ.LSBZ=2)
AND ( ZY_BQYZ.SYBZ = 0)
AND ( ZY_BQYZ.XMLX＜4 )
AND ( ZY_BQYZ.YZPB=0 )
AND ( ZY_BQYZ.FYSX＜2)
AND ( ZY_BQYZ.JFBZ＜2)
AND ( ZY_BQYZ.YSBZ = 0 OR (ZY_BQYZ.YSBZ = 1 AND ZY_BQYZ.YSTJ = 1))
在医院履行模块的数据窗口SQL：
SELECT DISTINCT
ZY_BQYZ.ZYH,ZY_BRRY.BRCH,ZY_BRRY.ZYHM,ZY_BRRY.BRXM,ZY_BRRY.BRXZ
FROM ZY_BQYZ, ZY_BRRY
WHERE ( ZY_BQYZ.ZYH = ZY_BRRY.ZYH )
AND ( ZY_BRRY.CYPB = 0 )
AND ( ZY_BQYZ.SRKS = :al_hsql )
AND ( ZY_BQYZ.SYBZ = 0 )
AND ( ZY_BQYZ.LSBZ = 0 OR ZY_BQYZ.LSBZ = 2 )
AND ( ZY_BQYZ.QRSJ ＜ :ad_today OR ( ZY_BQYZ.QRSJ IS NULL ) )
AND ( ZY_BQYZ.JFBZ = 2 OR ZY_BQYZ.JFBZ = 9 )
AND ( ZY_BQYZ.XMLX ＞ 3 )
AND ( ZY_BQYZ.YZPB = 0 )
ORDER BY ZY_BRRY.BRCH
4小结
从以上这些比如能够看出，SQL优化的本质便是在成果正确的前提下，用优化器能够辨认的句子，充份使用索引，削减表扫描的1/O 次数，尽量防止表查找的产生。其实SQL的功用优化是一个杂乱的进程，上述这些仅仅在SQL句子运用时的一种详细实例和平常运用中的总结。总归，数据库的功用优化是一个体系工程，触及的方面许多。数据库管理员需求归纳运用多种办法，仔细剖析数据库运转进程中呈现的各种问题，才干确保数据库高效地运转。
