这一阵子在做一个查询交易的压力测试，使用的AIX+informix数据库。应用和数据库分别部署在两台机器上。使用loadrunner进行并发测试。相关表的历史数据是20W级别的。使用20个并发进行测试。
测试过程中，应用服务器负载正常，数据库服务器磁盘、网络使用率正常，但是CPU使用率却是98%左右。觉得很奇怪，因为这台机器是测试环境中性能最好的，表现不应该如此。于是先猜测会不会是informix的参数配置不对，于是搜了些informix参数中影响CPU使用率的参数调了一遍，但是现象依旧。对里面查询的三张主表的SQL语句使用执行计划查看，查询也没有问题，都落在索引上了。直到前两天看到一篇文章，里面提到如果不确定哪段代码导致的性能问题，可以使用分段注释代码的方法定位是哪全代码的问题，于是也想可以把这个查询交易里面查询的所有表的SQL语句注释掉查找是操作哪张表里导致的。最后终于定位到是在查询另外一张数据量比较大的表时，在导数据的脚本中把一个索引给删了，导致走了另一个低效率的索引。以下是查询计划的部分内容：
QUERY: (OPTIMIZATION TIMESTAMP: 02-12-2015 14:33:42)
------
SELECT cust_num,bank_card FROM yw_zhzj where fund_card=‘fund_card0002456‘ and zjzt=‘0‘
Estimated Cost: 12456
Estimated # of Rows Returned: 2
1) ywk.yw_zhzj: INDEX PATH
Filters: ywk.yw_zhzj.zjzt = ‘0‘
(1) Index Name: ywk. 413_1682
Index Keys: cust_num bank_card fund_card dxjgdm cpdm (Key-First) (Serial, fragments: ALL)
Index Key Filters: (ywk.yw_zhzj.fund_card = ‘fund_card0002456‘ )
Query statistics:
-----------------
Table map :
----------------------------
Internal name Table name
----------------------------
t1 yw_zhzj
type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t1 1 2 200000 00:00.58 12456
可以看到虽然使用的是“INDEX PATH”，但是下面rows_scan是200000，这张表的数据量就是200000，那也就是全表扫描了。后来在yw_zhzj这张表中加上缺失的fund_card字段上的索引，数据库CPU使用率立马降到5%以下了。
猛然想起之前看到的一句话：数据库CPU使用率异常高，很有可能是某个大表在作全表扫描。可惜当时经验尚浅，仍旧一头扎到informix的参数调整里去了。现在回头看，总结两点：
1，CPU使用率高，但其他资源使用率正常，那绝对先考虑有数据量较大的表在作全表扫描。
2，方向很重要
3，注释法是个定位问题的杀手锏
不过对于执行计划，还是有点不明白，像上面这个例子，即使是对这张表的查询落在另一个索引上，那为什么还是作了全表扫描？因为那个索引里面 Index Keys包括cust_num bank_card fund_card dxjgdm cpdm，里面是有fund_card的，也不至于全表扫描啊。学艺不精，后续还要多多学习！
本文出自 “爱成长，爱生活” 博客，谢绝转载！
原文地址：http://yiqianghua.blog.51cto.com/2043853/1614354
