一个很老的调优案例

1. 问题现象
某银行系统业务处理很慢，无法正常做业务。

2. 问题分析
使用软件对数据库中运行的SQL 语句进行分析，发现一条语句执行时间在2 秒左右，被多次执行，占超过一半的全部CPU 执行时间。该语句为select * from cardinfo,并且是游标执行。进一步检查，在该游标需要取出的数据越多，执行越慢。

与开发人员确认，该cardinfo 记录不多，只有1000 行左右。每笔卡业务都需要首先读取该表，确认该卡的类型。程序使用游标定位卡的类型，即选出所有该表的数据，取出一条，根据条件进行判断：如果是，则取出需要的数据，终止该循环；如果未匹配，则继续取下一条数据。

此类型语句在数据库运行效率较差，通过分析可以看到，该语句的服务器执行时间很短，可以忽略不计；而网络的时间，即客户端处理的时间占了90%以上因此，解决该问题应该从提高客户端处理的效率出发，而优化数据库本身不会根本解决。

3. 问题解决
提高客户端网络交互效率有如下几种方法：
 替换游标为一般SQL 语句
 使用大数据包
 减少返回的行数
 一次返回多行

下面就这几种情况分别讨论：
1. 替换游标为一般SQL 语句
判断条件过于复杂，修改为一般语句有较大困难，未采取此方法。

2. 使用大数据包
是多次返回小数据包，使用大数据包不解决问题。

3. 减少返回的行数
虽然无法改变游标为普通SQL 语句，但可以限制该游标返回的结果集合。增加where 条件限制返回条件。

4. 一次返回多行
使用exec sql [at connection_name] open cursor_name [row_count = size], 在open
cursor 语句中加入row_count = n）。该方式不影响应用中的逐行处理方式。

采用了限制返回行数的方法，问题立刻得到解决。系统完全恢复正常。
一次返回多行也有很好的效果，在其它系统得到了验证。

不错,顶一个