4、好的数据来自生产环境。这是显而易见的，使用真实的数据测出来的结果才是准确的。但是绝大多数情况下，我们没有这样的好运，可能是客户禁止、也可能是生产环境数据量比较小。那只好自己想办法来模拟了，需要注意的也是上面说到的几点。这里再推荐一种方法，数据翻倍。比如已经有了真实的数据十万条，但我们需要一百万条，那可以通过写一些SQL或者存储过程，将现有的数据不断翻倍（简单的说，复制到临时表，根据需要修改一些列，再插回到原表），这样的数据真实性还是比较高的。

　　关于测试数据，我想说的是以上几点了。另外再补充上一些相关内容，也是性能测试人员需要关注的。

　　● 重点了解IO的概念，更准确的说应该是物理IO。一般来讲，数据库的瓶颈或者查询的主要耗时是IO。所以，数据库优化的一个重要方向是尽量减小IO。

　　IO是不是只和数据量（行数）有关呢？举一个例子：

select co1， col2， col3， col4， col5 from T_AJ
where condition...

　　T_AJ数据量有100万，表中有近200列，此查询耗时大于10秒。而另一种实现方式，首先将col1-col5以及查询条件中的几个列的数据抽取到一张临时表（#T_AJ）中。然后，

select co1， col2， col3， col4， col5
from #T_AJ where condition...

　　临时表#T_AJ和原数据表有同样的数据量（行数），但是此查询却只需要1秒（暂不考虑抽取到临时表的耗时），这是不同IO引起的差异。通常我们使用的数据库都是行式存储的，可以简单的理解为，一行数据从头读到尾，才能进入到下一行。这样，不管一行中的200列，你只读取其中的一列还是几列，其余的190多列仍然需要一定的IO。在大数据量下，这个性能差异很明显了。所以上面的这个例子是一种典型的优化手段，索引覆盖也是处理类似问题的典型方法，各位自行了解吧。列式存储数据库（如Sybase IQ）之所以性能这么高，也是同样的道理。

　　● 尽量深入了解这些概念，如执行计划，基于开销的估算，统计信息等等。我用一句话来简单描述：数据库通过统计信息来估计查询开销，统计信息不准时，开销估计可能不准确，从而导致选择了错误的执行计划。

　　● 测试过程中数据的清理。性能测试过程中可能又会生成大量的数据，积累到一定程度又会对性能结果造成影响，所以每一轮测试时都应该清理掉之前测试过程中产生的数据，保证每次测试是在相同的条件下进行的。

　　● 性能测试过程中，如果定位到了某一个查询或SQL有问题，首先要确认的是数据是否合理。通过查询计划来判断是否按预期进行了查询，如果不是，查看数据的分布是否真实。一般数据库会提供很多种手段来进行验证。

　　后，本文所写内容都是针对传统的行式存储数据库的，还请大家注意。