但在本例中不正常的数据条件下，数据库会知道：符合N_FY查询条件的数据有50万条，符合D_LARQ的也有近50万条，如果使用其中一列的索引将一百万的范围缩减到50万，比从头到尾扫描整个表做的工作还要多（为什么呢？需要了解索引的结构和原理），那还是不要用索引了吧。于是数据库会依次检查每一条数据，判断N_FY和D_LARQ是否符合条件。

　　注：本图中实际扫描的数据量是整张表的数据，但结果集和图一是一样大的。

　　这样，可以知道，总数据量一样，结果集大小一样，为什么性能差了很多了。是因为数据分布不合理，导致数据库无法正常使用索引，从而进行了全表扫描。当然，这个数据分布，我们依然可以归类到结果集中去，那是要保证每一个查询条件“单独的结果集”都要符合真实情况，而不仅仅是整个查询终的“总结果集”。

　　看个这两个简单的小例子，我们再来总结一下关于测试数据，需要注意的内容：

　　1、根本、也是大家都知道的是数据量，性能测试必须保证能在预期的数据量下进行测试。在一万条记录中查询，和在一百万数据中查询，显然是大大不同的，可以把数据量看做一种“压力”，这个不用再解释了。

　　但是在比较大型的系统中，这一点可能也不是很容易做好，因为这类系统往往有着复杂的数据库，上百张的数据表。对每张表都进行数据模拟显然是不现实的，也是没有意义的，因为不是每张表都涉及到大数据量。那么如何选取不容易遗漏呢？通常通过两种方式：从设计和业务角度分析表间关系、从现有实际数据量进行分析推测。

　　2、确保结果集在正常范围内。结果集的大小直接影响后续很多工作的性能，如数据排序分组、分页、程序中的逻辑校验或者是展现。

　　3、数据分布必须合理，尽量接近真实。数据的分布，其实也是数据的真实性，它直接决定了数据库是否使用索引、选用哪个索引，也是常说的查询计划。不同的查询计划也是不同的数据访问路径，性能差别可能会很大。

　　这里主要涉及到的是索引的问题，需要大家对索引的原理有一定的了解，索引如何工作、数据库如何选择索引、和索引有关的一写重要概念如区分度（selectivity）等等。