怎样判断一个查询性能低是由于缓冲池命中率导致的

Technote (troubleshooting)


本文档仅适用于以下语言版本：
简体中文
问题（摘要）
一些查询，特别是那些读数据量大的查询，性能有时候会毫无征兆地降低或者升高。这很有可能是缓冲池（buffer pool）命中率变化导致的。本文将简单介绍判断一个查询的性能变化是否是由缓冲池命中率导致的方法。
症状
相同的查询，在 DB/DBM 配置和应用都没有变化的情况下，有时候运行时间只需要几秒，有时候却需要数分钟，且Runstats也不能提高性能。


原因
如果查询所需的大部分数据或者索引数据都可以重缓冲池读取，那么查询将很快完成；而如果需要从磁盘读取较多数据页，那么查询性能将大大降低。
诊断问题
运行下面的命令以获取查询执行的信息：
db2batch -d <dbname> -f <file> -o p 5 -r x.out


在上面命令的返回结果里面，我们可以找到类似下面有用的信息：


* Elapsed Time is: 1623.546004 seconds
Buffer pool data logical reads = 2654789 ,
Buffer pool data physical reads = 142438
Buffer pool index logical reads = 10070752 ,
Buffer pool index physical reads = 12118
Rows read = 2501199


Total buffer pool read time (milliseconds) = 1597453


从上面我们可以看到总共执行时间是1623秒，磁盘读取等待时间是1597.453秒 - 这相当于95%的时间花在了磁盘读取上面。
注意： Total buffer pool read time - 指的是从物理表空间读取数据和索引页所占用的总时间，单位是毫秒。


再次运行上面的命令，我们可能会得到一个不同的结果：


* Elapsed Time is: 6.967117 seconds
Buffer pool data logical reads = 2512351 ,
Buffer pool data physical reads = 0
Buffer pool index logical reads = 10058636 ,
Buffer pool index physical reads = 0
Rows read = 2501199
Total buffer pool read time (milliseconds) = 0


我们可以看到：
- 相同查询运行时间： 7s vs 1623s
- 执行计划前后没有变化，"Rows read" 前后完全一样。
- 第二次执行磁盘读取页为0，在6.9秒就完成执行。


解决问题
该问题可以通过调整缓冲池，或者调整查询以使其读取较少数据解决。