`
septem
  • 浏览: 53168 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

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

    博客分类:
  • sql
阅读更多
本章讨论数据量增加时面对的特殊挑战,包括如何高效地搜索庞大的表,如何避免数据量稍有增长就可能出现的性能下降

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

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

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

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

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

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

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

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

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

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

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

归档并清除数据常被看作辅助手段,不过归档与清除数据是极敏感的操作,处理不好可能会造成性能上的问题
1
0
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics