一边是开发环境，一边是product环境；两边的硬件几乎完全一致。开发环境下升级了数据库软件，要全面比较差异后，把product环境升级。要比较一下两者在各种操作上的运行速度、IO吞吐、内存使用等各个方面的差异，应该如何入手。1， 都有哪些方面应当注意
2， 针对不同的方面有什么样的测试方法
3， 是否有比较完备的思路可以直接参照，或者有现成的工具使用。以前接触的数据库操作少，所以越具体越好。
2， 针对不同的方面有什么样的测试方法
3， 是否有比较完备的思路可以直接参照，或者有现成的工具使用。以前接触的数据库操作少，所以越具体越好。
最好含主表和从表。
数据集弄成20-100万行，应该就差不多了。
2. load这个数据集，统计时间
3. 执行几次单表查询，以及关联查询，统计时间
4. 执行几次update操作，统计时间
基本上这些就可以覆盖了
2、使用statspack分别在开发与正式环境作一个报告来对比。
这两个环境在我测试的时候可以认为无须模拟，运行一样的后台程序，而且当时是美国的晚上，几乎没有人工操作的。硬件环境也一致。使用的是sybase数据库，不知道是否有类似工具。sybase相对冷清点，在这里想找点通用的思路。
现在发现了一点问题。之前有人比较过一个存储过程的时间，新版本的开发环境700ms，Prod上150ms；感觉差距比较大了。
头暂时不让在prod环境下实验，我看了一下执行计划，发现还是有区别的，有人能给解释一下吗？
1、这个叶面大小是哪个参数确定的？据我观察之前的几十个statement都是2kb，只有这个是16kb，也是从这个开始I/O cost不一致了。
2、如果是系统自动选择的大小，如何强制为2kb。（我想强制后看一下结果）
3、如何解释这个I/O cost；这个cost和谁成正比，是I/O 次数，还是次数*I/0叶面大小dev:
QUERY PLAN FOR STATEMENT 85 (at line 540).
STEP 1
The type of query is SELECT.
Evaluate Ungrouped COUNT AGGREGATE. FROM TABLE
rate_sched
Nested iteration.
Using Clustered Index.
Index : rate_sched_PUC
Forward Scan.
Positioning by key.
Keys are:
asset_id ASC
Using I/O Size 16 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages. STEP 2
The type of query is SELECT.Total estimated I/O cost for statement 85 (at line 540): 190.PROD：
QUERY PLAN FOR STATEMENT 85 (at line 540).
STEP 1
The type of query is SELECT.
Evaluate Ungrouped COUNT AGGREGATE. FROM TABLE
rate_sched
Nested iteration.
Using Clustered Index.
Index : rate_sched_PUC
Forward scan.
Positioning by key.
Keys are:
asset_id ASC
Using I/O Size 2 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages. STEP 2
The type of query is SELECT.Total estimated I/O cost for statement 85 (at line 540): 80.