DEV Community
·
优化SpringData SQL查询中的N+1问题之旅
💡
原文英文，约1200词，阅读约需5分钟。
📝
内容提要
在预生产环境中，首页加载时间过长，经过调查发现存在严重的N+1问题。通过调整FetchType和使用Entity Graph，成功优化了数据库查询，消除了N+1问题，从而提升了性能。
🎯
关键要点
- 在预生产环境中，首页加载时间过长，发现存在严重的N+1问题。
- 数据库查询中执行了849个额外的SELECT查询，导致性能下降。
- FetchType.EAGER导致N+1问题，误认为它能优化查询。
- FetchMode定义了Hibernate如何获取数据，FetchType定义了加载方式。
- 移除FetchType.EAGER并使用FetchMode.JOIN未能解决问题。
- Spring Data内部使用Criteria API，FetchMode.JOIN无效。
- 设置FetchType.LAZY在@OneToOne关系上未能生效，因为Project不是关系的拥有者。
- 解决N+1问题的方法是移除Project模型中的@OneToOne关系注解。
- 使用Entity Graph可以指定Spring Data进行JOIN操作，优化查询。
- 最终通过移除关系和使用Entity Graph解决了N+1问题，提升了性能。
- 建议通过编写SQL测试来调试SQL性能问题，能更快迭代。
❓
延伸问答
什么是N+1问题，它是如何影响性能的？
N+1问题是指在数据库查询中，除了主要的SELECT查询外，还会执行大量额外的SELECT查询，导致性能下降。在文章中，执行了849个额外的查询，严重影响了首页加载时间。
如何通过FetchType和FetchMode优化Spring Data查询？
通过设置FetchType.LAZY和使用FetchMode.JOIN可以优化查询，但在Spring Data中，FetchMode.JOIN通常无效。最终，使用Entity Graph来指定JOIN操作是更有效的解决方案。
为什么FetchType.EAGER会导致N+1问题？
FetchType.EAGER会强制立即加载所有相关数据，导致在查询时产生大量额外的SELECT查询，从而引发N+1问题。
如何使用Entity Graph解决N+1问题？
使用Entity Graph可以指定Spring Data进行JOIN操作，从而优化查询，避免N+1问题的发生。
在Spring Data中，为什么FetchMode.JOIN无效？
FetchMode.JOIN在Spring Data中无效，因为Spring Data内部使用Criteria API，而Criteria API不考虑FetchMode的设置。
解决N+1问题的最终方案是什么？
最终方案是移除Project模型中的@OneToOne关系注解，并使用Entity Graph来优化查询，从而消除N+1问题。
➡️
