SQL语言艺术(十)集中兵力：应付大数据量

本章讨论数据量增加时面对的特殊挑战，包括如何高效地搜索庞大的表，如何避免数据量稍有增长就可能出现的性能下降

在达到目标数据量之前，第一次严重的性能问题通常会出现。当数据量较少时，从最终用户的角度看不出糟糕的查询和糟糕的算法的影响。硬件本身的处理能力会隐藏巨大错误，完整扫描几十万条记录也不到一秒时间，我们可能严重地滥用硬件能力来弥补程序的错误，直到数据量变得相当可观时，真正的错误才被发现

当项目第一次出现性能危机时，通常会进行“专家调优”，增加几个本应一开始就有的索引。接下来的系统可能不太稳定，直到数据达到目标量。第二个性能危机通常会随着实际目标量的到来而出现。当系统投入生产环境，架构设计的弱点被重新评估，一些关键处理被积极重写，系统最后稳定下来

这些错误通常都会出现，也都能够得到解决，不过造成无法挽回失败的，是数据库设计错误和架构选择错误。编程时我们必须预先考虑数据量的增加，而且面对逐渐增加的数据量时，必须尽快找出使性能快速恶化的查询并改写它们

不同数据库操作对数据量增加的敏感程度不同，要预先考虑查询对不同数据量的执行方式

受数据量增加的影响不大，比如基于主键的搜索，常见的B树索引，其结构趋于扁平，效率很高

受到数据量增加的线性影响，比如聚合函数，可以考虑对要处理的数据设定上限，让数据量保持在控制范围内

受到数据量增加的非线性影响，比如排序。读取较大的有序集合时，性能降低一点并不奇怪，而且通常较大型的排序需要将有序子集临时存储到慢得多的硬盘中。所以，通过调整分配给排序的内存数量来改善排序密集型操作的性能，是常见且有效的调优技巧

被排序的总数据量增加时，会导致显著的性能降低，所以攻取额外信息的join操作，应该延后到查询的最后阶段，即先对核心信息进行排序，再join其它的表。但要注意，由于排序是非关系层操作，这时优化器会比较保守，只尽量优化内层查询，排序聚合等操作阻止了优化器将内层查询与外层查询混合，最终，查询基本上按原始的编写方式执行

为了降低查询对数据量增加的敏感度，应该在较深层的查询中只操作绝对必要的数据，将辅助性的join操作留在外层

关联子查询在计算每一条返回记录时都被调用一次，应尽量减小关联子查询对外层查询元素的依赖性

当结果集在被检查记录中占的比例很高时，表扫描会较高效。如果使用分区，搜索条件就可以只操作表的一部分物理单元，从而使扫描效率极大提升。此时，对合理分区的部分进行大范围扫描，反而会比使用索引协助检查范围边界值更高效。当然，分区并不能解决所有大数据量的问题，分区必须注意分区键的分配均衡，数据范围的边界，包括上限和下限必须明确定义

归档并清除数据常被看作辅助手段，不过归档与清除数据是极敏感的操作，处理不好可能会造成性能上的问题