为何。基本上，正常路径是先扫描orders表，接着利用orderstatus表上预计非常高效的索引进

    行访问。在最后一版的代码中，我们改用完整扫描orderstatus的方法，这是为了执行group by。

    orderstatus中的记录条数一定会比orders 中的大好几倍，然而，只以要扫描的数据量来看，

    估计前者比较小（而且可能小很多），这取决于为每张订单保存了多少信息。

    无法确定哪种方法一定更好，这一切都取决于实际数据。补充说明一点，最好别在预期会增大

    的表上做全表扫描cāo作（若能把搜索限制在最近一个月或几个月的数据上则会好些）。不过，最

    后一版的代码肯定比第一版的（在where子句用子查询）要好。

    在结束“大数据量查询”的话题之前，有个特殊情况值得一提。当查询要返回非常大量的数据时，

    该查询很可能不是某个用户坐在电脑前敲入的命令，而是来自于某个批处理cāo作。即便“预备阶

    段”稍长，只要整个处理能达到令人满意的结果，就是可以接受的。当然，不要忘了，无论是不

    是预备阶段，都会需要资源——CPU、内存，可能还有临时磁盘空间。即使最基本的查询完全

    相同，优化器在返回大量数据时所选择的路径，仍可能会与返回少量数据时完全不同，了解这

    一点是有用的。

    总结：尽早过滤掉不需要的数据。

    取出数据在表中的比例

    The Proportions of Retrieved Data

    有个典型的说法：当查询返回的记录数超过表中数据总量的10% 时，就不要使用索引。这种

    说法暗示，当（常规）索引的键指向表中不足10%的记录时，它是高效的。正如第3章中所指出

    的，这个经验法则建立于许多公司仍对关系数据库有所怀疑的年代，那时，关系数据库一般用

    于部门级数据库，包含十万行数据的表就被认为是大型表。与含有五亿行数据的表相比，十万

    行的10% 不值一提。所以，执行计划“佳者恒佳”仅是个美好的愿望罢了。

    就算不考虑“10%的记录”这条“经验法则（rule of thumb）”产生的年代（现在的表大小早已今非

    昔比了），要知道，返回的记录数除了与期望响应时间有关之外，它本身并无意义。例如，计算

    十亿行数据的某字段的平均值，虽然返回结果只有一行，但DBMS 要做大量工作。甚至没有任

    何聚合处理，DBMS要访问的数据页的数量也会造成影响。因为要访问的数据页并非只依赖索

    引：第3章曾指出，表中记录的物理顺序与索引顺序是否一致，对要访问的页数有极大影响；第

    5章将讨论的一些物理实现也会造成影响，由于数据的物理存储方式不同，检索出相同数量的记

    and o.custid = c.custid

    录所要访问的数据页数量可能差异很大；此外，有的访问路径将以串行方式执行，有的则以大

    规模并行（parallelized）方式执行……。因此，再别拿“10%的记录”这根鸡毛当令箭了。

    总结：当查询的结果集很大时，索引未必必要。

    SQL

    语句为了返回结果集或更改数据，必须访问一定数量的数据。“

    战斗”

    的环境和条件，决定