优化ORM性能：避免N+1问题与LightSpeed ORM调优

147 浏览量更新于2024-08-28 收藏 163KB PDF 举报

"优化ORM性能是开发人员面临的重要课题，尤其是在处理大型、复杂的数据访问场景时。ORM（Object-Relational Mapping）技术虽然可能带来一定的性能损失，但如果正确使用并进行适当的调优，其与手动编写原生代码在性能上可以达到相近水平。例如，Mindscape的LightSpeed ORM是一个值得信赖的工具，它通过提供预加载（Eager Loading）功能来解决常见的N+1问题。 N+1问题是一种常见的性能瓶颈，它发生在当查询一个包含多个关联对象的集合时，每条记录都会独立发起额外的数据库查询来获取关联数据。如上述示例所示，遍历一个过期订单列表时，如果不对关联的客户信息进行预加载，会导致数据库查询次数成倍增长。对于100个过期订单，原始代码将执行101次查询，这是非常低效的。通过预加载，ORM框架如LightSpeed允许开发人员在查询时一次性加载相关的关联数据，避免了重复查询。只需在查询时指定EagerLoading为True，或者使用EagerLoadAttribute标记关联属性，框架会在内部生成相应的SQL语句来获取这些关联数据，从而在数据访问时只涉及对象属性，不再引发额外的数据库查询，从而消除了N+1问题。在使用LightSpeed ORM时，合理利用预加载机制可以显著提升性能，减少不必要的网络通信和数据库交互。然而，这并不意味着所有情况都适合使用预加载，因为它可能会增加内存消耗。开发者需要根据具体的应用场景和性能需求，权衡预加载带来的好处与潜在的内存占用。优化ORM性能的关键在于理解并合理运用ORM框架提供的特性，如预加载，以及根据实际情况调整查询策略。通过这些手段，可以确保在保持开发灵活性的同时，实现高效的数据访问和处理。"

优化优化ORM性能性能

有些开发者因为曾有性能上的不快经验而拒绝采用对象关系映射（ORM）技术。和任何形式的抽象一样，使用ORM框架要以

一些额外开销作为代价，但事实上，使用经过恰当调优的ORM和手写原生的数据访问代码在性能上还是有得一拼的。更为重

要的是，使用好的ORM框架更容易调优和优化性能，手写原生数据访问代码在性能调优上则会困难得多。

本文中的示例建立在Mindscape的LightSpeed ORM之上，我们将结合示例讨论常见的问题及其解决方案。

N+1问题

让我们来看看web应用程序中的过期订单列表，这有助于我们理解所要讨论的问题。假设我们不仅要查看订单，同时还要查看

每个订单的客户信息，如果没做深入分析的话，我们也许会写出这样的代码：

var overdues = unitOfWork.Orders.Where(o => o.DueDate < today);

foreach (var o in overdues) // 1

{

var customer = o.Customer; // 2

DisplayOverdueOrderInfo(o.Reference, customer.Name);

}

这段代码隐藏着所谓的N+1问题。获取订单列表（代码中注释1处）需要一次数据库查询操作，接着代码会获取列表中每个订

单对应的客户信息，而每次获取都得进行一次数据库查询！所以，如果总共有100个过期订单，代码就得执行101次数据库查

询——第1次用于加载过期订单集合，后续100次用于加载每个订单的客户。一般来说，有N个订单就得执行N+1次数据库查询

——这就是N+1问题名称的由来。

显然，这是相当慢和低效的。我们可以通过预先加载（eager loading）技术解决这种性能问题。如果我们能将所有关联客户

的加载作为订单查询操作的一部分，在同一次数据库访问中进行，那么后面对客户信息的访问就只是访问对象属性而已——不

需要查询数据库，也就没有N+1问题。

使用LightSpeed，我们可以通过将EagerLoading设置为True（或者，在手写业务实体中应用EagerLoadAttribute）来预先加载

关联的数据。当LightSpeed查询设置了预先加载关联的实体时，除了“主体”实体本身，它还将产生相应的SQL语句用以查询关

联的实体。

在上面的例子中，如果我们在Order.Customer关联上应用预先加载，那么当我们查询Order实体时，LightSpeed将会产生用于

加载Order实体和Customer实体的SQL语句，并将所有语句同批处理。这样，只要稍作改动，就可以将101次数据库访问减少

为1次。

ORM和原生数据访问代码之间的映射

总的来说，这表明为什么ORM框架具有性能调优上的优势。假设过期订单页面使用了手写的SQL，并手动将数据库访问层中

的数据复制到实体对象中，则当N+1问题出现时，你不仅要更新SQL语句，还要更新你的映射代码以处理多种结果集和管理对

象关系。对于我们的简单例子，这些工作量并不算很多，但如果页面要从很多数据库表中读取数据就不是这样了。那要比修改

一个选项和应用一个attribute麻烦得多！

延迟加载（Lazy Loading）

上述的订单页面存在另外一个潜在问题。让我们假设Customer实体有一个包含大图片的Photo属性（如果你对销售部门做个需

求调查，就会发现这是合情合理的）。过期订单页面不需要访问Customer.Photo属性，但相片和Customer对象的其他属性值

一样，都会被加载。如果相片很大，这将消耗很多内存，并且需要很长时间才能从数据库提取出所有相片数据——而最后这些

时间都浪费了。

解决上述问题的方法是让Photo属性延迟加载——具体说就是只当属性被访问时才加载数据，而不是在加载Customer实体时就

加载。因为过期订单页面不访问Photo属性，也就不会加载不需要的图片；而其他确实需要相片的页面，比如客户简介页面，

仍然能直接访问Photo属性。

并没有一个简单的标识可以用来设置启用延迟加载机制的属性。但是你可以将属性标识为named aggregate的一部分（通过在

属性的Aggregate设置中输入称），这样的属性默认是延迟加载的。下一节中我们会详细讨论这项技术。

下载后可阅读完整内容，剩余3页未读，立即下载

weixin_38705788

粉丝: 6
资源: 907

优化ORM性能：避免N+1问题与LightSpeed ORM调优

ORM自定义框架

浅谈优化Django ORM中的性能问题

.NET Orm性能测试分析

django_orm查询性能优化方法

优化Django ORM性能：策略与工具

ORM性能优化：解决N+1问题

Django ORM性能优化策略：从数据库到视图

Hibernate ORM框架详解与性能优化

SSH框架面试精华：封装、ORM与性能优化

【Django信号与ORM性能优化】：优化策略，提升数据库操作效率

最新资源