关于使用数据库优化提示的建议(第二部分).pdfVIP

让我给你一些关于使用数据库优化提示的建议 － 第二部分 作者: Richard To 2007 年 7 月 20 日星期五 原文：/products/sql-optimizer-for-oracle/b/weblog/archive/2007/07/20/let-me-give-you-a- hint-on-using-database-optimization-hints-part-two.aspx 想要参阅优化提示系列的第一部分你可以查看我的上一篇文章。 为关键任务系统(Mission Critical System)使用提示 (Hints) 对于关键任务系统 (Mission Critical System)，你可能不希望冒着改变数据库的物理结构的风 险而只是为了解决少部分 SQL 语句的性能问题。利用提示(Hints) 或重写 SQL 语句是提升系统性能非 常安全的方法，它没有引入任何物理结构变化，如新的索引、物化视图、柱状图、或者表分区等等， 因为通过重写语法去应用新的提示 (Hints) 是个隔离的事件。这种方法通常不会给其它的SQL 语句带 来负面的影响。 为访问数据量波动大的表的 SQL 使用提示 (Hints) 当数据量不时地急剧上升或下降时，很多问题都是由访问那些表的 SQL 引起的。下面列举了其中 一些问题： 1. Oracle 不能及时更新它的统计信息 2. 统计信息采样结果不正确 3. 一个旧的被缓存在内存中的计划不能正确地处理那些表的 4. 优化器的成本估算法偏离了很多聚集操作的步骤 5. 处理高度倾斜的数据分布的直方图粒度不足够小 6. 在计划空间生成期间，由于复杂的 SQL 语句使得大的计划空间消减下来，而导致最佳的执行 计划可能被丢失。 7. 其它… 其实，这些理由也存在于你的系统中的多数的问题 SQL 语句中，所以你可能想帮数据库的优化器 解决这些问题。提示 (Hints) 和 SQL 重写是对付那些问题的尖端武器。在任何时候，它不仅帮助数据 库的优化器去挑选正确的执行计划，而且它将不会影响其它 SQL 语句的性能。 可靠的性能要求 我记得大约 15 年前，当时我是一名 Sybase 的数据库管理员(DBA)，工作于一个医院系统。在那 时，Sybase 是第一个带有基于成本的 SQL 优化器的数据库。在那个应用数据库中，除了 Patients 表 有多于 20 万条记录外，每个表都是小表。那个系统上线后第一个月运行得很好。没想到，我接到了一 个医院运营商的投诉。那个系统挂起了并且他们无法得到任何请求的响应。经调查后，我发现一个经 常被执行的在线查询运行不到一秒钟就不见了，并且一个小时后也没有完成。我检查了执行计划并将 它与开发数据库中的执行计划进行对比。结果我发现一个嵌套循环 (Nested Loop)连接方向被改变了, 将“从小表到索引循环 Patients 表” ( “small tables to index loop Patients table”)改为“索 引循环Patients 表连接小表” ( “Patients table index loop join small tables”)了。显然，问 题是优化器错误地计算了该执行计划的成本，并且大表 Patients 有一个嵌套循环 (Nested Loop)。我 只好通过重写 SQL 语句来纠正这种错误。 所以，你可能会发现一条每天正被执行数万次的关键 SQL 语句经不起任何性能的下降，不管是多 么小的改变。从 0.1 秒到 0.15 秒的一个变化可能是性能的灾难。为了确保数据库的优化器不会由于统 计信息和数据库环境变化的不可预知性破坏了你的职业生涯，你可能想为了不冒险还是使用硬编码将 提示 (Hints)添加进你经常执行的和关键任务的 SQL 语句中。 在优化提示 (Optimization Hints)系列的最后一部分，我会指出提示(Hints)是否会限制了将来 优化的灵活性和探索你的数据库的潜能。