程序代码未使用绑定变量对医院信息系统健康运行的危害性
原理：语句的解析过程
关键判断指标项：每秒解析量
每秒解析量过高（也称解析过量），通常意味着正在运行的程序未采用绑定变量来书写代码。
未使用绑定变量问题的危害
1、直接危害：解析过量会导致系统资源被大量占用（主要是CPU，内存资源），影响整个业务系统数据库的性能。
2、间接危害：解析过量因为占用资源，造成事务执行时间变长，间接引起各种非空闲等待事件增加，进而造成业务系统的卡慢问题。
未使用绑定变量问题的危害案例1
假设某大型三甲医院每天的门诊挂号量约为10000次。
情况1：门诊程序的挂号事务对应SQL代码采用绑定变量的方式
这时所有的挂号事务被数据库看成是同一种事务处理方式，只是具体到每一次挂号事务带入的变量值不同，比如病人的姓名、挂号的科室、编号等。由于所有的挂号事务是作为同一种事务进行处理的，因此，只需要在第1次事务请求时，产生一次SQL语句的解析，生成和保存一个执行计划，以后所有挂号请求就都可以复用这个执行计划。情况1的资源开销我们可以描述为：CPU开销为1，内存开销为1。
情况2：门诊程序的SQL代码未采用绑定变量的方式
这个时候数据库系统是无法分辨是否是同一种事务处理方式的。所以每一次挂号请求都会进行SQL解析，产生一条新的执行计划。如此，每天10000次挂号请求，则每次数据库系统都需生成一条新的执行计划，每一个执行计划都需要在内存中找到地方存放，则情况2的资源开销为：CPU开销为10000，内存开销为10000。
即在这个例子中，未使用绑定变量的情况下，CPU和内存的开销约为使用绑定变量时的10000倍。
问题处置建议
对于此类解析过量问题，通常有如下建议：
由于解析过量的问题是SQL语句中未使用绑定变量引起的，所以此类问题主要由系统软件开发人员或开发厂商进行处理，针对程序质量进行针对性的改进，具体建议如下：
（1）业务已进入生产运营阶段：由于整体修改程序代码的成本较高，建议采取折中方法，采用工具软件（如全景软件）或人工命令筛选出解析频繁度TOP5的语句（具体方法请参考下列真实案例）只对这些TOP语句进行绑定变量的优化，从而实现在工作量尽量少的情况下，最大程度的改善解析过量造成的系统资源开销过高情况。如果TOP5语句优化后开销仍然较高，可以再依次选取TOP6以后的更多语句进行优化，直至资源开销变为正常。
（2）业务尚处在研发测试阶段：督促相关的开发者，建立严格的开发规范，业务软件的代码书写要求应严格使用绑定变量；开发完成后，进行严格的测试，可配合使用全景软件，发现代码中存在的硬解析问题，减少系统上线后产生的性能问题，降低上线后修改程序的成本。
使用全景软件发现及定位解析过量的问题
真实案例
（1）问题发现：登录全景软件——问题溯源模块，发现2021年11月存在大量的解析过量问题，由于此问题是存在程序代码中的问题，点击其中某次信息查看即可，例如查看2021-11-09 9:00解析过量问题块。
上图蓝色矩形即代表着检测到解析过量事件的时间区间，从中我们可以看到一个规律，因为解析过量属于程序代码质量问题，因此只要程序运行，就会受到该问题的影响，所以对存在解析过量问题的业务程序，往往在业务的高峰，严重的甚至是每天的整个业务运行时段，都会不断报告出现解析过量事件。
（2）查看详细信息：通过点击问题，查看SQL文本，我们以解析频繁度和总执行时间两个维度进行降序排列，得到TOP10 解析过量SQL，以第一个语句为例，该语句为“select * from OUTPATIENT_Record where 唯一标识=000375177400.6”该语句为业务系统（本例为电子病历系统）频繁执行的一条语句，该查询语句的where子句未使用绑定变量，会造成CPU开销增加，进而影响整个业务系统的性能。
建议先从解析频繁度TOP5的语句开始优化，即由绑定常量，改为绑定变量
下期分享
医院业务软件健康管理实战案例分享（四）
