数据库性能是一个永无止境的话题，IT专业人士——尤其是DBA——似乎永远谈不完，我想这是因为数据库应用程序的性能是最终用户抱怨最多的问题之一。
如果DBA能迅速解决性能问题，他们就能成为英雄。当然，性能问题之所以如此普遍，也可能是因为人们总是在设计和编码时犯同样的错误。
我经常被问到这样的问题：“为了确保数据库性能良好，我应该重点关注什么?”这无疑是一个充满陷阱的问题，但我认为自己能够回答。
因此，基于这个提问，且在没有其他信息的情况下，让我们来看看我对两个最关键“要点”的看法，这些要点能帮助您有效管理数据库和 SQL 应用程序。
1、保持统计信息最新
没有统计信息，关系优化器就无法进行准确的优化。数据库统计信息提供了关于数据库中数据状态和组织结构的信息。
优化器会将这些统计信息与SQL语句中使用的表进行匹配，并应用查询成本公式来确定获取数据的最 佳方式。关系型优化器会收集以下类型的统计信息：
表详细信息，包括总行数、压缩率和总块数
列详细信息，包括离散值的数量以及每列中存储的值的分布范围
表空间信息，例如活动页数和聚簇率
索引统计信息，包括叶子页(leaf page)的数量和层级、索引键的离散值数量，以及索引是否为聚集索引
有关表空间、索引节点组或分区的其他信息
统计信息是在执行实用程序或命令时生成的——具体取决于使用的数据库管理系统(DBMS)，例如 RUNSTATS 或 UPDATE STATISTICS，请务必与DBA合作，在生产环境中适时收集统计信息。
2、构建合适的索引
与收集最新统计信息同样重要的是，确保您为表创建了正确的索引。当然，这说起来容易做起来难。但我们可以从一些基础知识开始。例如，考虑以下SQL语句：
SELECT LASTNAME, SALARY
FROM EMP
WHERE EMPNO = ‘000010’
AND DEPTNO = ‘D01’;
对于这个简单的查询，创建哪些索引才是合理的?首先，请思考所有可能创建的索引。您的初步清单可能如下所示：
基于EMPNO 的 Index1
基于DEPTNO 的 Index2
基于EMPNO 和 DEPTNO 的 Index3
这是一个不错的开端，而 Index3 可能是最 佳选择。它允许数据库管理系统(DBMS)利用该索引立即查找满足 WHERE 子句中两个简单谓词的行。如果你已经在 EMP 表上创建了大量索引，那么在该表上再创建一个索引可能会产生影响，因此需要仔细评估。以下是需要考虑的一些因素：修改影响：DBMS 必须自动维护您创建的每个索引。这意味着每行插入和每行删除操作不仅会影响表本身，还会影响其索引。此外，如果您更新了索引中包含的列的值，也会更新索引。因此，索引虽然能加快检索速度，但会减慢修改操作。
现有索引中的列：如果 EMPNO 或 DEPTNO 上已经存在索引，那么在两者的组合上再创建另一个索引可能并非明智之举。不过，修改现有索引以添加缺失的列或许是可行的——但并非总是如此，索引中列的顺序会根据查询的不同产生显著影响。例如，考虑我们之前的查询。
在此情况下，索引中应将 EMPNO 列在首位，DEPTNO 列在第二位。这样，数据库管理系统(DBMS)可以对第一个列(EMPNO)进行直接索引查找，然后对第二个条件(DEPTNO)进行扫描。
此外，如果这两个列都已存在索引(一个针对 EMPNO，一个针对 DEPTNO)，某些 DBMS 产品可以同时使用这两个索引来满足此查询，这意味着可能无需创建新的索引。
每个查询的重要性：查询越重要，就越需要通过创建索引来进行调优。如果您正在编写 CEO 每天都会运行的查询，那就需要确保其能提供最 佳性能，为这样的特定查询构建索引非常重要。然而，针对普通职员的查询可能重要性较低，因此该查询使用现有索引即可。这一决策取决于应用程序对业务的重要性，而不仅仅是用户的地位。
重载：此外，您还可以考虑通过索引重载来实现仅索引访问。如果 SQL 查询所需的所有数据都包含在索引中，数据库管理系统(DBMS)可能仅凭索引就能满足该请求。再次以之前的查询为例，我们查询了 LASTNAME 和 SALARY，并给出了关于 EMPNO 和 DEPTNO 的信息。我们最初是在 EMPNO 和 DEPTNO 列上创建了索引，如果我们将 LASTNAME 和 SALARY 也包含在索引中，就永远不需要访问 EMP 表，因为所需的所有数据都存在于索引中。这种技术可以通过减少 I/O 请求的数量来显著提高性能。
请注意，试图让每个查询都仅通过索引访问既不现实，也不明智，应将此技术保留给特别棘手或重要的 SQL 语句。恰当的索引设计涉及的内容远不止本文所能涵盖的范围，这里仅触及了基础部分。
总结
如果您是数据库性能管理的初学者，请务必从本文简短介绍的两点内容开始入手。
但请记住，我们对这两个领域的探讨仅是冰山一角。在统计信息收集和索引设计方面，进一步的研究和学习将使您受益匪浅。如果您是资深的数据库专业人士，重新温习这些主题也绝无坏处。您可能会了解到一些尚未使用过的新特性或功能，或者仅仅是巩固已有的知识。
作者：Craig S. Mullins
