使用EntityFrameWork 5.0面向存储过程(&执行Sql,性能优化)

EntityFrameWork5.0简单使用

概要:

使用EntityFrameWork5.0执行存储过程,Sql语句(DDL/DML)以及一点关于优化性能的方面;

正文:

在myef.tt下会包含需要展示数据的存储过程(select)

模型浏览器如下,

1.EF如何调用存储过程:

Note:数据库的表对应的实体,以类对象表示,在EF容器下可以直接操作,比如db.UserAccount直接拿到UserAccount实体对象,存储过程,视图也是同样道理,也是可以通过EF上下文容器得到;

2.EF执行Sql语句:

Note:两种情况,一种是查询sql,一种是非查询sql;都是定义在上下文容器下的Database对象;其中SqlQuery<T>()方法支持泛型;

3.EF性能优化

<1>延迟加载与缓存机制

一般都是ToList()之后才会去执行sql,一般由Where(),Count(),Any()等操作后是生成sql语句,在运行到调用的时候才会去执行sql(或者手动ToList());

另外在同一个上下文容器下,如果重复查询数据,会有缓存机制来优化,不会再次发送sql去执行,而是从缓存中直接复用;

<2>不跟踪查询

当我们查询到数据后,上下文容器会将这些数据的state标识为unchanged来进行管理,如果接下来并需要再对查询到的数据进行保存更改删除等操作,可以用不跟踪查询,让上下文容器不再跟踪查询数据以提高性能;

4.面向存储过程编程

END!

时间: 2024-10-03 21:54:31

使用EntityFrameWork 5.0面向存储过程(&执行Sql,性能优化)的相关文章

SQL Select count(*)和Count(1)的区别和执行方式及SQL性能优化

SQL性能优化:http://www.cnblogs.com/CareySon/category/360333.html Select count(*)和Count(1)的区别和执行方式 在SQL Server中Count(*)或者Count(1)或者Count([列])或许是最常用的聚合函数.很多人其实对这三者之间是区分不清的.本文会阐述这三者的作用,关系以及背后的原理. 往常我经常会看到一些所谓的优化建议不使用Count(* )而是使用Count(1),从而可以提升性能,给出的理由是Coun

数据仓库中的 SQL 性能优化(Hive篇)

一个Hive查询生成多个map reduce job,一个map reduce job又有map,reduce,spill,shuffle,sort等多个阶段,所以针对hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会有细分),针对MR全局的优化,和针对整个查询(多MR job)的优化,下文会分别阐述. 在开始之前,先把MR的流程图帖出来(摘自Hadoop权威指南),方便后面对照.另外要说明的是,这个优化只是针对Hive 0.9版本,而不是后来Hortonwork发起Stinger

Oracle SQL性能优化

转载自:http://www.cnblogs.com/rootq/archive/2008/11/17/1334727.html (1)      选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection ta

SQL性能优化案例分析

这段时间做一个SQL性能优化的案例分析, 整理了一下过往的案例,发现一个比较有意思的,拿出来给大家分享. 这个项目是我在项目开展2期的时候才加入的, 之前一期是个金融内部信息门户, 里面有个功能是收集各个上市公司的财报, 然后做各种分析, 数据图表展示, 使用的人数并不多, 仅百人左右. 2期打算面向行外用户, 刚开始预计同时在线人数不超过50, 就以50访问用户/秒的性能测试, 结果在把1期的图表类数据展示响应基本在5分钟左右, 属于严重不可用, 说说我们的服务器配置, 有2台网站前端承载用户

&lt;转&gt;Oracle SQL性能优化

原文链接:http://www.cnblogs.com/rootq/archive/2008/11/17/1334727.html (1)      选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection t

关于SQL性能优化的十条经验

1.查询的模糊匹配 尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用. 解决办法: 其实只需要对该脚本略做改进,查询速度便会提高近百倍.改进方法如下: a.修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了. b.直接修改后台——根据输入条件,先查出符合条件的供应商,并把相关记录保存在一个

1.SQL优化系列--&gt;高手详解SQL性能优化十条经验

1.查询的模糊匹配 尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用. 解决办法: 其实只需要对该脚本略做改进,查询速度便会提高近百倍.改进方法如下: a.修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了. b.直接修改后台——根据输入条件,先查出符合条件的供应商,并把相关记录保存在一个

Oracle SQL性能优化系列

1. 选用适合的ORACLE优化器 ORACLE的优化器共有3种: a. RULE (基于规则) b. COST (基于成本) c. CHOOSE (选择性) 设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你当然也在SQL句级或是会话(session)级对其进行覆盖. 为了使用基于成本的优化器(CBO, Cost-Based Optimizer) , 你必须经常运行an

SQL性能优化前期准备-清除缓存、开启IO统计

如果需要进行SQl Server下的SQL性能优化,需要准备以下内容: 一.SQL查询分析器设置: 1.开启实际执行计划跟踪. 2.每次执行需优化SQL前,带上清除缓存的设置SQL. 平常在进行SQL Server性能优化时,为了确保真实还原性能问题,我们需要关闭SQL Server自身的执行计划及缓存.可以通过以下设置清除缓存. 1 DBCC DROPCLEANBUFFERS --清除缓冲区 2 DBCC FREEPROCCACHE --删除计划高速缓存中的元素 3.开启查询IO读取统计.查询