oracle10g数据库开发优化指南.docVIP

ORACLE10G数据库开发 优化指南 目录 目录 2 1：绑定变量 3 2：不要频繁提交，不要使用自动提交 5 3：索引 7 什么情况下适合建立索引： 7 如何使优化器使用索引： 8 4：高效SQL 10 查询中使用索引 10 表联结查询 11 5：常见的、流传很广的传言 13 6：临时表的使用 15 7：autotrace 16 8：收集统计信息 17 1：绑定变量 绑定变量是一个数据库开发人员所应该具备的最基本的习惯之一。 但是在现实中，很多开发人员完全不使用绑定变量，甚至根本不知道绑定变量是何物。这个很大程度上是因为他们不了解使用或者不使用绑定变量对数据库造成的影响。如果他们知道了，我敢肯定他们一定会很吃惊。 任何一句提交给ORACLE数据库运行的语句，在正式运行前，都需要通过数据库引擎的解析。解析分为2种，一种是硬解析，一种是软解析。为了理解方便，简单的说，如果你使用了绑定变量，那么数据库会倾向于使用软解析，如果你没有使用绑定变量，那么数据库会倾向于使用硬解析。 从字面上理解，硬解析使用的资源会比软解析多。但是到底有多少？很难在这个文章里面进行全面描写，但是可以从其中的一个方面进行理解：在一个SQL语句的硬解析中，会产生数百个乃至数千个LATCH，而这些LATCH锁住的都是数据库必须在实例级别串行访问的资源，并且请注意，这么多的LATCH是硬解析一句SQL语句中产生的！软解析则不需要产生这些LATCH。单从这一点就可以知道，硬解析对数据库而言是一个极其昂贵的操作。如果开发人员在一个循环里面调用了一个SQL语句而又没有绑定变量，那么可以想象对数据库会造成多大的压力！ **************************************************************************** LATCH不等于锁LOCK，它是一种轻量级的LOCK，用来保证对资源的串行访问。对于被LOCK住资源的申请，如果不能满足，那么申请者会被阻塞以后进入一个等待队列等待，当资源被释放的时候，按照先到先得的顺序唤醒队列里面的第一个等待者。而对被LATCH住的资源的申请，如果不能满足，那么申请的进程不会被阻塞也不会等待，它只会在很短的一个时间以后再次重新申请。申请LATCH住资源的进程能否得到这个资源全凭运气：它们不会排队等待，而是随机的去碰运气—不停的尝试申请。 **************************************************************************** CURSOR_SHAREING参数是ORACLE提供的一个对于不使用绑定变量的解决方案，它如果设置成FORCE，可以在数据库实例上对所有提交给数据库的SQL语句强制进行绑定变量。这看来好象是对开发人员的一种解放，但是，请注意下面2点： 1：CURSOR_SHAREING会引入它自己的额外开销。 2：它有可能会引发一些与手动绑定变量不同的、不可意料的SQL执行返回结果，这增加了测试和排错的难度。 CURSOR_SHAREING绝对不是解决绑定变量的万能方法，相反，它这是ORACLE提供的一种不得已而为之的解决方案，只有当运行系统因为硬解析而不堪重负，而短期又不可能全面重写代码的情况下使用的，而且使用以前一定要经过充分严格的测试。 当然，过度绑定变量是有可能导致某个查询性能下降的，实际中也会有这样的场景。但是，相比较而言，不使用绑定变量而带来的性能问题要更普遍和严重得多。 以JAVA为例，所有提交给数据库执行的SQL语句应该如下面这样绑定变量。 { Connection con = DriverManager.getConnection (jdbc:oracle:oci:@database,scott,tiger); conn.setAutoCommit(false);//把自动提交修改为非自动提交。 String v_sql = select name from table_a where id = ? ; //嵌入绑定变量 ReparedStatement stmt = conn.prepareStatement( v_sql ); stmt.setString(1, xxxx ); //为绑定变量赋值 stmt.executeQuery(); mit(); } 所以，请开发人员特别注意：除非有充分的理由，否则，请确保你提交给数据库执行的任何一句SQL语句都是手工绑定了变量