关键字：数据库设计
结构化查询语言(SQL)对于关系型DBMS是把双刃剑，利弊参半。因为从关系型数据库检索任何数据都需要SQL，本文所要探讨的话题就是：不论是终端用户还是开发人员或是数据库管理员（DBA），他们将如何访问一个关系型数据库。当使用高效的SQL时,系统会变得易于升级、灵活、而且便于管理。当使用低效的SQL时,响应时间和程序运行时间都会延长，并且还会产生应用系统的中断。鉴于通常的数据库系统一般要花费90%的处理时间用于从数据库检索数据，由此很明显的可以看出尽可能的保证SQL的高效是多么的重要。考察通常的SQL语句问题譬如"SELECT*FROM"仅是冰山一角,我们将在本文中探讨其他容易确定的普遍的问题。需要记住的是,检索得到同一数据的SQL语句有很多种殊途同归的写法，所以不存在好的查询语句或是坏的查询语句，而只有满足适当需求的查询语句。各关系型数据库都有自己的方式来优化和执行查询语句。因此，各DBMS都拥有自己的最佳性能的查询技巧。本文将使用Quest软件中QuestCentralforDB2的例子和概述来集中讨论DB2forOS/390和z/0S。
图1：DB2Engine和一些组件介绍
图2：DB2优化器验证过的列和用来确定的存取路径
要是在十七年前，这张技巧单会更长，并且会包含对最小化的SELECT场景的矫正方法。每一个新版本的DB2都会增加成千上万行的新代码，用以扩展智能优化，和查询重写及执行。例如，多年来一种被称为数据管理器的组件,通常被提供作为"第一阶段处理"以增加它的过滤容量一百倍。另一组件是关系型数据服务器，通常被提供作为"第二阶段处理"来进行其主函数的查询重写和优化。另一关键组件就是基于当前的SQL，并使用存取路径以决定检索数据的DB2优化器。DB2优化器改善了每一个DB2的版本,考虑到另外的DB2目录中的统计,可以提供新的和改善过的存取路径。图1显示了这些组件及其他更多的部分，并描述了DB2如何处理数据或SQL的请求。这就是以下DB2SQL性能技巧的来源。
在这篇文章中，我们将回顾一些更具有代表性的SQL问题，有更多的SQL方面的性能技巧超出了本篇文章描述的范围。像所有指导方针一样，所有这些技巧也会有一些例外。
技巧1：核实是否提供了适当的统计:
对于DB2优化器来说，最重要的资源除了SELECT语句本身，就是DB2目录中创建的统计。优化器基于众多的选择而使用这些统计。DB2优化器为了查询而选择一条非最佳存取路径的主要原因，归结于无效的或缺失的统计。DB2优化器使用以下目录统计:
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
