当前，在我们需要在面向对象的编程范例中开发应用程序时，基于以下原因，使用 ORM框架 是一种常见的做法：

· 关系世界与对象世界不能直接兼容。

· RDBMS （关系数据库管理系统）的多样性引入了将对象转换为每个RDBMS期望的特定SQL命令的复杂性。

所以我们所需要的就是包含一个ORM框架，比如 hibernate 或者EclipseLink，所有的问题都会得到解决?我不这么想。这些框架在我们开发时产生了新的关注点，这些关注点可以用一个词来描述:性能。我所从事的项目在性能上存在问题，由于开发人员认为没有必要担心这个问题，因为ORM框架已经为他们解决了这个问题，所以必须对这些项目进行重构。结果是交付的应用程序运行了，但是性能很差。

为了避免在生产中出现重构或意外，我建议您在使用 JPA 提供者或直接使用ORM框架开发应用程序时采用以下实践:

在关联中使用默认的FetchMode值

默认在JPA FetchMode值建议当你不想松散的时间评估最好的策略应用,关系类型一对一或者多对一的映射(non-collection字段/属性)，必须急切和一对多，多对多的关系类型(收集字段/属性)相映射。

如果您想优化关系映射，请考虑使用延迟策略， ORM 为每个查询执行多个SQL语句，并使用即时策略，ORM可以加载比实际需要更多的数据。最好的解决方案是评估和平衡每种策略的缺点。

请定义批处理大小和获取大小

ORM框架提供了定义批处理大小和获取大小的配置。这些配置允许在执行SELECT和INSERT等语句时进行优化。

以Hibernate为例，可以定义以下配置属性:

ORM框架提供定义批量大小和获取大小的配置。这些配置允许在执行SELECT和INSERT等语句时进行优化。

以Hibernate为例，可以定义以下配置属性：

· hibernate.default_batch_fetch_size ：Hibernate批量提取关联的默认大小。如果您具有使用提取模式LAZY配置的关联，或者在查询中未使用JOIN FETCH，则此属性适用。

示例1 ：1个包含100行和1个关联的表的查询将在批量大小配置为值1时生成100个SQL语句。

示例2 ：1个与1个包含100行和1个关联的表相关的查询将生成25个SQL批量大小配置为值4时的语句。

· hibernate. jdbc .fetch_size ：非零值通过调用Statement.setFetchSize（）来确定JDBC获取大小。当您要在内存中加载更多数据时，此属性适用。此属性的值越高，与服务器的通信越低，因此性能越好。但要小心，高值会占用应用程序中更多的内存，并可能导致OutOfMemoryError异常。我认为10到50之间的值是合理的。

· hibernate.jdbc.batch_size ：非零值会导致Hibernate使用JDBC2批量更新。当您要执行一批INSERT命令时，此属性适用。但要小心，我不建议使用JPQL来执行大量的INSERT命令。在这种情况下，尽可能使用本机查询来减少开销。

使用NEW运算符编写查询

当您编写查询并仅在SELECT子句中声明实体时，ORM框架将加载表的此表示形式的所有列以及使用JOIN声明的关联的所有列。此外，未使用JOIN声明的所有关联都将从分离的查询中加载，并且也将被视为SELECT子句中的所有列。

为了减少网络中不必要数据的流量并减少每个请求到RDBMS的应用服务器中存储的数据量，我建议使用NEW运算符。此运算符允许我们仅声明我们需要通过实体或DTO（数据传输对象）类的构造函数加载的字段/列。

示例 ：

考虑具有两个关联的实体Foo，一对多称为bar和baz。该实体有15个字段映射到RDBMS。

如果只需要检索3个字段，则可以编写以下优化查询：

SELECT NEW Foo(f.field1, f.field2, f.field3)

FROM Foo f JOIN f.bar bar

WHERE f.field10 = :valueToField10 AND bar.id = :valueToBarId

使用join ferch 关联查询

当您编写查询以检索与您的实体具有的关联相关的某些字段值时，我建议使用JOIN FETCH语句。使用此语句可减少ORM框架生成的查询数，以实现所需的结果，甚至可以减少到只有一个查询。

示例 ：

考虑具有两个关联的实体Foo，一对多称为bar和baz。

如果只需要在一个查询中检索实体Foo的所有关联，则可以编写以下查询：

SELECT DISTINCT f FROM Foo f JOIN FETCH f.bar bar JOIN FETCH f.baz baz 
WHERE f.field10 = :valueToField10 AND bar.id = :valueToBarId
 

注意：包含DISTINCT命令是为了消除由于将JOINFETCH用于集合表示的关联而可能出现在结果中的实体的重复。

使用分页查询

当您执行查询以返回行集合作为结果而不指定分页参数时，ORM框架将检索与查询相关的所有行（实体）并将它们存储在内存中，如果返回不是，则会导致不必要的内存被占用。

要减轻或消除此内存占用，请考虑JPA规范，使用接口Query或TypedQuery提供的以下方法：

· setFirstResult（int）：期望一个参数指示页面的偏移量。

· setMaxResults（int）：预期一个参数来指示页面的限制。

因此，可以使用这些方法来限制查询结果并减少使用的内存量并减少应用程序和RDBMS之间的网络流量。

示例 ：

想象一下，您编写了一个与包含100万行的表相关的查询。如果执行此查询而不对WHERE子句有任何条件，则将在内存中检索100万行，结果将是在应用程序中产生大量内存消耗。但是如果在与分页参数相同的条件下执行此查询，则可以控制返回并存储在内存中的行数，这是我认为的最佳方法。

使用 二级缓存 （L2/2LC）

默认情况下，JPA规范或ORM框架启用了第一级缓存（L1 / 1LC）。这种类型的缓存适用于每个事务，即缓存在每个事务期间都可用，并允许减少对RDBMS的访问。但是如果要进一步减少对RDBMS的访问次数，则需要使用二级缓存（L2 / 2LC）。考虑到一个或多个应用程序服务器，这种类型的缓存可用于跨多个事务（EntityManagers）工作。

起初，2LC可以被认为是一个很大的问题; 但是，需要考虑这背后的问题，如下所述：

· ORM只读或插入的对象应该不是问题。

· ORM通过其他应用程序或服务器更新或删除的对象可能导致这些对象变得陈旧，即变得不一致。

因此，我建议首先应用2LC来攻击不受不一致性影响的问题，以及在导致与应用程序操纵的所涉及的RDBMS对象的完整评估不一致的问题之后。

要通过JPA和Hibernate规范启用2LC，请参阅此处的以下说明。

注意：由于缓存的灵活性，ORM框架通常比JPA规范更强大。

尽可能使用本机查询

当您编写主要是复杂查询并且您的应用程序只需要在一个RDBMS供应商（例如PostgreSQL，Oracle数据库）中工作时，我建议您使用命名本机查询或本机查询来减少JPQL解析器产生的内存消耗。如果查询是用SQL ANSI编写的，那么当您的应用程序需要与多个RDBMS供应商合作时，也可以应用此方法。

还有其他方法可以在不通过ORM框架的情况下减少消耗，例如：使用缓存预准备语句设置数据源。

禁用SQL调试

在生产环境中，将用于在控制台上显示SQL语句的属性的值配置为false。这并不是什么新鲜事，但我认为注册很重要，不要忘记注册。

其他与绩效相关的实践

· 在RDBMS上索引表列以提高性能。

· 分析执行计划以确定如何优化您的查询。

总结

ORM框架功能强大，大大减少了我们的工作，但你必须负责任并正确地使用正在构建的内容，以便在实际交付到生产环境时不会影响应用程序的性能。

end：如果你觉得本文对你有帮助的话，记得点赞转发，你的支持就是我更新动力。