通过分析 SQL 语句的执行方案优化 SQL(总结)第 1 章 性能调整综述第 2 章 有效的应用设计第 3 章 SQL 语句处理的过程第 4 章 ORACLE 的优化器第 5 章 ORACLE 的执行方案 访问路径(方法) -- access path 表之间的连接 如何产生执行方案 如何分析执行方案 如何干预执行方案 - - 使用 hints 提示 具体案例分析第 6 章 其它本卷须知附录第 1 章 性能调整综述 Oracle 数据库是高度可调的数据库产品。本章描述调整的过程和那些人员应与 Oracle 效劳器的调整有关，以及与调整相关联的操作系统硬件和软件。本章包括以下方面:l 谁来调整系统?l 什么时候调整?l 建立有效调整的目标l 在设计和开发时的调整l 调整产品系统l 监控产品系统谁来调整系统: 为了有效地调整系统，假设干类人员必须交换信息并牵涉到系统调整中，例如:l 应用设计人员必须传达应用系统的设计，使得每个人都清楚应用中的数据流动.l 应用开发人员必须传达他们选择的实现策略，使得语句调整的过程中能快速、容易地识别有问题的应用模块和可疑的 SQL 语句.l 数据库管理人员必须认真地监控系统活动并提供它们的资料，使得异常的系统性能可被快速得识别和纠正.l 硬件 / 软件管理人员 必须传达系统的硬件、软件配置并提供它们的资料，使得相关人员能有效地设计和管理系统。 简而言之，与系统涉及的每个人都在调整过程中起某些作用，当上面提及的那些人员传达了系统的特性并提供了它们的资料，调整就能相对的容易和更快一些。 不幸的是，事实上的结果是：数据库管理员对调整负有全部或主要的责任。但是，数据库管理员很少有适宜的系统方面的资料，而且，在很多情况下，数据库管理员往往是在实施阶段才介入数据库，这就给调整工作带来许多负面的影响，因为在设计阶段的缺陷是不能通过 DBA 的调整而得以解决，而设计阶段的缺陷往往对数据库性能造成极大的影响。 其实，在真正成熟的开发环境下，开发人员作为纯代码编写人员时，对性能的影响最小，此时大局部的工作应由应用设计人员完成，而且数据库管理员往往在前期的需求管理阶段就介入，为设计人员提供必要的技术支持。调整并不是数据库管理员的专利，相反大局部应该是设计人员和开发人员的工作，这就需要设计人员和开发人员具体必要的数据库知识，这样才能组成一个高效的团队，然而事实上往往并非如此。什么时候作调整？ 多数人认为当用户感觉性能差时才进行调整，这对调整...
