[NHibernate]N+1 Select查询问题分析

目录

写在前面

文档与系列文章

N+1 Select查询问题分析

总结

写在前面

在前面的文章(延迟加载,立即加载)中都提到了N+1 Select的问题,总觉得理解的很不到位,也请大家原谅,这也是为什么单独将该问题拿出来做分析的原因。nhibernate的默认Lazy加载方式是解决N+1 select问题的一种方案,而我自身的理解是立即加载可以解决,完全的背道而驰了。写出那篇文章后,对这个问题,一直念念不忘,总觉得哪地方不对劲。由于我对问题的理解很不透彻,也同样造成你的误解,真的很抱歉。

文档与系列文章

[Nhibernate]体系结构

[NHibernate]ISessionFactory配置

[NHibernate]持久化类(Persistent Classes)

[NHibernate]O/R Mapping基础

[NHibernate]集合类(Collections)映射 

[NHibernate]关联映射

[NHibernate]Parent/Child

[NHibernate]缓存(NHibernate.Caches)

[NHibernate]NHibernate.Tool.hbm2net

[NHibernate]Nullables

[NHibernate]Nhibernate如何映射sqlserver中image字段

[NHibernate]基本配置与测试 

[NHibernate]HQL查询 

[NHibernate]条件查询Criteria Query

[NHibernate]增删改操作

[NHibernate]事务

[NHibernate]并发控制

[NHibernate]组件之依赖对象

[NHibernate]一对多关系(级联删除,级联添加)

[NHibernate]一对多关系(关联查询)

[NHibernate]多对多关系(关联查询)

[NHibernate]延迟加载

[NHibernate]立即加载

[NHibernate]视图处理

N+1 Select查询问题分析

使用sql查询数据的时候,如果select太多,势必也会对数据库造成压力,影响性能。比如如果查询n个Customer对象,则一次查询获得所有的customer对象,然后根据customerid查询关联的Order表。(立即加载的情况下

一个例子

 1         /// <summary>
 2         /// NHibernateUtil方式,立即加载客户信息及关联的数据
 3         /// </summary>
 4         /// <param name="customerID"></param>
 5         /// <returns></returns>
 6         public Customer GetCustomerByImmediatelyLoadNHibernateUtil(Guid customerID)
 7         {
 8             //获得ISession实例
 9             //通过using的方式将session释放,为了保证是立即加载的数据,而不是延迟加载的
10             //还记得上篇文章中提到的在延迟加载中,在关闭session情况下,再读取数据的时候就会有一个异常信息
11             //忘记的可以再回到上一篇文章进行查看
12             using (ISession session = NHibernateHelper.GetSession())
13             {
14                 Customer customer = session.Get<Customer>(customerID);
15                 //
16                 // 摘要:
17                 //     Force initialization of a proxy or persistent collection.
18                 //
19                 NHibernate.NHibernateUtil.Initialize(customer.Orders);
20                 return customer;
21             }
22         }

这里使用NHinernateUtil实用类进行强制立即加载方式,测试代码

1         protected void btnImmediately_Click(object sender, EventArgs e)
2         {
3             Business.CustomerBusiness customerBusiness = new Business.CustomerBusiness();
4             Customer customer = customerBusiness.GetCustomerByImmediatelyLoadNHibernateUtil(new Guid("B0720295-9541-40B3-9994-610066224DB8"));
5             bool isInitOrder = NHibernate.NHibernateUtil.IsInitialized(customer.Orders);
6         }

查看生成的sql语句

本来我们是想查询customer,一次查询就够,可是通过监视到的sql,发现多了一次sql查询,也就是查询customer的关联数据表的数据。

而在延迟加载的情况下,则会在需要的时候才会去查询,性能上面更好。(有关延迟加载的内容,请在系列文章中查找,这里不再赘述了)

如果采用延迟加载方式,生成的sql如下(借用延迟加载文章中的图说明)

一对多关系Lazy加载

多对多关系Lazy加载

order和Product多对多关系,此时生成的sql语句

你可以看到此时生成的sql语句是通过left outer join(左外连接)进行关联数据表的,而此时只生成一条sql语句,明显减少了查询数据的次数。

总结

(1)select语句的数目太多,需要频繁的访问数据库,会影响检索性能。此时可采用sql中的左外连接查询,在一条sql语句中将所有数据查询出来,并且减少了select的次数。
(2)在应用逻辑只需要访问Customer对象,而不需要访问Order对象的场合,加载Order对象完全是多余的操作,这些多余的Order对象白白浪费了许多内存空间。
为了解决以上问题,Hibernate提供了其他两种检索策略:延迟检索策略和迫切左外连接检索策略。延迟检索策略能避免多余加载应用程序不需要访问的关联对象,迫切左外连接检索策略则充分利用了SQL的外连接查询功能,能够减少select语句的数

这里就N+1 select问题做一下特别说明,有问题,如果不想办法解决,总觉得有个疙瘩,早解决,早有好心情。通过本篇的分析,你是不是也对n+1的问题豁然开朗?这也怪我了,当时对那一块理解确实有误,再次感到很抱歉。

时间: 2024-10-27 10:35:22

[NHibernate]N+1 Select查询问题分析的相关文章

为什么忘记commit也会造成select查询的性能问题

今天遇到一个很有意思的问题,一个开发人员反馈在测试服务器ORACLE数据库执行的一条简单SQL语句非常缓慢,他写的一个SQL没有返回任何数据,但是耗费了几分钟的时间.让我检查分析一下原因,分析解决过后,发现事情的真相有点让人哭笑不得,但是也是非常有意思的.我们先简单构造一下类似的案例,当然只是简单模拟. 假设一个同事A,创建了一个表并初始化了数据(实际环境数据量较大,有1G多的数据),但是他忘记提交了.我们简单模拟如下: SQL> create table test_uncommit   2 

Solr4.8.0源码分析(5)之查询流程分析总述

Solr4.8.0源码分析(5)之查询流程分析总述 前面已经写到,solr查询是通过http发送命令,solr servlet接受并进行处理.所以solr的查询流程从SolrDispatchsFilter的dofilter开始.dofilter包含了对http的各个请求的操作.Solr的查询方式有很多,比如q,fq等,本章只关注select和q.页面下发的查询请求如下:http://localhost:8080/solr/test/select?q=code%3A%E8%BE%BD*+AND+l

让OData和NHibernate结合进行动态查询

OData是一个非常灵活的RESTful API,如果要做出强大的查询API,那么OData就强烈推荐了.http://www.odata.org/ OData的特点就是可以根据传入参数动态生成Entity Framework的查询,最终实现动态的SQL的查询.但是在项目有时我们并没有采用Entity Framework,而是采用的NHibernate,那么该怎么用OData呢? 经过一段时间的Google和研究,终于找到了一个好的方案. 在OData API查询时,用户前端是url跟参数,但是

慢查询日志分析工具mysqldumpslow

mysqldumpslow是mysql自带的一种慢查询日志分析工具,顾名思义,就是查询那些出那些查询慢的SQL语句,由此分析出SQL查询效率慢的原因. 通常来说,mysqldumpslow分组查询的结果是相似的,它在展示统计结果时,可以将数字和字符串分别抽象成"N"和"S".当然也可以用-a 和 -n选项可以用来修改这些抽象的行为. mysqldumpslow查询命令 mysqldumpslow [options] [log_file] mysqldumpslow可

mysqli_stmt类:使用预处理语句处理SELECT查询结果

SELECT语句和其他的SQL查询命令不同,它需要处理查询结果.SQL语句的执行也需要使用mysqli_stmt对象中的execute()方法,但与mysqli对象中的query()方法不同,execute()方法的返回值并不是一个mysqli_result对象.mysqli_stmt对象提供了一种更为精巧的办法来处理SELECT语句查询结果:在使用execute()方法执行SQL语句完成查询之后,使用mysqli_stmt对象中的bind_result()方法,把查询结果的各个数据列绑定到一些

hive 子查询特别分析

转自: http://blog.csdn.net/ls3648098/article/details/9630357 Hive只支持在FROM子句中使用子查询,子查询必须有名字,并且列必须唯一:SELECT ... FROM(subquery) name ... 确认下是否一定要求列必须唯一? 建表语句: create table  tb_in_base ( id  bigint, devid bigint, devname string ) partitioned by (job_time b

select查询的性能

为什么忘记commit也会造成select查询的性能问题 今天遇到一个很有意思的问题,一个开发人员反馈在测试服务器ORACLE数据库执行的一条简单SQL语句非常缓慢,他写的一个SQL没有返回任何数据,但是耗费了几分钟的时间.让我检查分析一下原因,分析解决过后,发现事情的真相有点让人哭笑不得,但是也是非常有意思的.我们先简单构造一下类似的案例,当然只是简单模拟. 假设一个同事A,创建了一个表并初始化了数据(实际环境数据量较大,有1G多的数据),但是他忘记提交了.我们简单模拟如下: SQL> cre

mysql 慢查询日志分析

mysql慢查询: 慢查询相关的变量 slow_query_log:该参数控制着慢查询的状态, 1表示开启状态 ,0 表示关闭状态 slow_query_log_file:慢查询日志路径 long_query_time:最大查询阀值,查询的时间超过这个值就视为慢查询并且将其记录到慢查询日志中,慢查询日志路径 通过slow_query_log_file 这个变量设置 log_queries_not_using_indexes:没有使用到索引的查询语句是否记录到慢查询日志中. log_slow_sl

大数据江湖之即席查询与分析(下篇)--手把手教你搭建即席查询与分析Demo

上篇小弟分享了几个"即席查询与分析"的典型案例,引起了不少共鸣,好多小伙伴迫不及待地追问我们:说好的"手把手教你搭建即席查询与分析Demo"啥时候能出?说到就得做到,差啥不能差人品,本篇只分享技术干货,目的只有一个,就是让每一个伙伴都能根据本篇向导搭建出一个"即席查询与分析Demo". 为了让各位伙伴能够尽快上手体验,所选案例就以上一篇中的"机动车缉查布控即席查询与分析"为例,上篇我们已经比较详尽的分析了用户需求,没好好听课的