Hibernate性能优化的.pdfVIP

Hibernate 性能优化 Hibernate 用法和特性只要使用过或许都很简单，但是要做到发挥 Hibernate 最大限度的潜力，Hibernate 优化 ，或者说 Hibernate 性能优化笔者仅仅是初窥门径而已。 索引调优 HQL 看起来和 SQL 很相似。从 HQL 的WHERE 子句中通常可以猜到相应的 SQL WHERE 子句。WHERE 子句中的字段决定 了数据库将选择的索引。 大多数 Hibernate 开发者所常犯的一个错误是无论何时，当需要新 WHERE 子句的时候都会创建一个新的索引。因为索引会 带来额外的数据更新开销 ，所以应该争取创建少量索引来覆盖尽可能多的查询。 让你使用一个集合来处理所有可能的数据搜索条件。如果这不太实际，那么你可以使用后端剖析工具来创建一个针对应用程 序涉及的所有 SQL 的集合。基于那些搜索条件的分类，你最终会得到一个小的索引集。与此同时，还可以尝试向WHERE 子句中添加额外的谓语来匹配其他 WHERE 子句。 范例 有两个 UI 搜索器和一个后端守护进程搜索器来搜索名为 iso_deals 的表。第一个 UI 搜索器在 unexpectedFlag、dealStatus、 tradeDate 和 isold 属性上有谓语。 第二个 UI 搜索器基于用户键入的过滤器，其中包括的内容除 tradeDate 和 isold 以外还有其他属性。开始时所有这些过滤器 属性都是可选的。 后端搜索器基于 isold、participantCode 和 transactionType 属性。 经过进一步业务分析，发现第二个 UI 搜索器实际是基于一些隐式的 unexpectedFlag 和 dealStatus 值来选择数据的。我们 还让 tradeDate 成为过滤器的必要属性（为了使用数据库索引，每个搜索过滤器都应该有必要属性）。 鉴于这一点，我们依次使用 unexpectedFlag、dealStatus、tradeDate 和 isold 构造了一个复合索引。两个 UI 搜索 器都能 共用它。（顺序很重要，如果你的谓语以不同的顺序指定这些属性或在它们前罗列了其他属性，数据库就不会选择该复合索 引。） 后端搜索器和 UI 搜索器区别太大，因此我们不得不为它构造另一个复合索引，依次使用 isold、participantCode 和 transactionType。 绑定参数 vs.字符串拼接 既可以使用绑定参数构造 HQL 的WHERE 子句，也可以使用字符串拼接的方法，该决定对性能会有一定影响。使用绑定参 数的原因是让数据库一次解析 SQL ，对后续的重复请求复用生成好的执行计划，这样做节省了CPU 时间和内存。然而，为 达到最优的数据访问效率，不同的绑定值可能需要不同的 SQL 执行 计划。 例如，一小段数据范围可能只返回数据总量的 5% ，而一大段数据范围可能返回数据总量的90%。前者使用索引更好，而后 者则最好使用全表扫描。 建议 OLTP 使用绑定参数，数据仓库使用字符串拼接，因为 OLTP 通常在一个事务中重复插入和更新数据，只取少量数据； 数据仓库通常只有少量 SQL 查询，有一个确定的执行计划比节省 CPU 时间和内存更为重要。 要是你知道你的 OLTP 搜索对不同绑定值应该使用相同执行计划又该怎么办呢？ Oracle 9i 及以后版本在第一次调用绑定参数并生成执行计划时能探出参数值。后续调用不会再探测，而是重用之前的执行计 划。 聚合及排序 你可以在数据库中进行聚合和“order by”，也可以在应用程序的服务层中事先加载所有数据然后做聚合和“order by”操 作。推荐使用前者，因为数据库在这方面通常会比你的应用程序做得好。此外，这样做还能节省网络带宽，这也是一种拥有 跨数据库移植性的做法。 当你的应用程序对数据聚合和排序有 HQL 不支持的特定业务规则时除外。 1 / 9 本地查询 本地查询调优其实并不直接与 HQL 有关。但 HQL 的确可以让你直接向底层数据库传递本地查询。我们并不建议这么做，因 为本地查询在数据库间不可移植。 抓取策略调优 抓取策略决定了在应用程序需要访问关联对象时，Hibernate 以何种方式以及何时获取关联对象。我们在此将关注它的使用 方法。 覆盖抓取策略 不同的用户可能会有不同的数据抓取要求。Hibernate 允许在两个地方定义数据抓取策略，一处是在映射元数据中，另一处 是在 HQL 或 Criteria 中覆盖它。 常见的做法是基于主要的抓取用例在