SQL存储过程放在SQL数据库中，因此在程序中调用的时候不必自己拼接sql语句。数据库会对存储过程进行预编译，因此速度快。3，在网络上不必传输冗长的SQL语句，而是直接调用存储过程的名字，因此可以加快速度当然，在一些外包软件开发中，是不允许使用存储过程的。因为对方不可以把数据库暴露给你，此时你只能使用SQL语句。不过国内的一些小型企业使用SQL存储过程还是很流行的。因为程序代码里不包含SQL语句，因此会数据库会相对安全一些。
Ⅱ 用ETL组件实现和sql相比哪个效率高
楼主好，我现在正在做BI相关的东西。如果ETL和SQL来说，肯定是SQL效率高的多。但是双方各有优势，先说ETL，ETL主要面向的是建立数据仓库来使用的。ETL更偏向数据清洗，多数据源数据整合，获取增量，转换加载到数据仓库所使用的工具。比如我有两个数据源，一个是数据库的表，另外一个是excel数据，而我需要合并这两个数据，通常这种东西在SQL语句中比较难实现。但是ETL却有很多现成的组件和驱动，几个组件就搞定了。还有比如跨服务器，并且服务器之间不能建立连接的数据源，比如我们公司系统分为一期和二期，存放的数据库是不同的，数据结构也不相同，数据库之间也不能建立连接，这种情况下，ETL就显得尤为重要和突出。通过固定的抽取，转换，加载到数据仓库中，即可很容易实现。
那么SQL呢？SQL事实上只是固定的脚本语言，但是执行效率高，速度快。不过灵活性不高，很难跨服务器整合数据。所以SQL更适合在固定数据库中执行大范围的查询和数据更改，由于脚本语言可以随便编写，所以在固定数据库中能够实现的功能就相当强大，不像ETL中功能只能受组件限制，组件有什么功能，才能实现什么功能。
所以具体我们在什么时候使用ETL和SQL就很明显了，当我们需要多数据源整合建立数据仓库，并进行数据分析的时候，我们使用ETL。如果是固定单一数据库的数据层次处理，我们就使用SQL。当然，ETL也是离不开SQL的。
Ⅲ java程序中写sql语句和存储过程 哪个效率高些
1、存储过程是已经编译过的，在执行时效率高
2、在程序中的SQL语句，每次都要经过数据库服务器的编译、校验、索引选择、缓存选择等等步骤。相对存储过程是慢的
3、当然也有些事情是必须要在程序中处理，例如：字符串的处理，各种情况的判断等，这个不能一概而论，需要具体场景具体分析，然后选择最优的方法来试用。
Ⅳ 项目中优化sql语句执行效率的方法是什么
1. SQL优化的原则是：将一次操作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。
调整不良SQL通常可以从以下几点切入：
? 检查不良的SQL，考虑其写法是否还有可优化内容
? 检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写
? 检查优化索引的使用
? 考虑数据库的优化器
2. 避免出现SELECT * FROM table 语句，要明确查出的字段。
3. 在一个SQL语句中，如果一个where条件过滤的数据库记录越多，定位越准确，则该where条件越应该前移。
4. 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引，这样查询时只进行索引扫描，不读取数据块。
5. 在判断有无符合条件的记录时建议不要用SELECT COUNT （*）和select top 1 语句。
6. 使用内层限定原则，在拼写SQL语句时，将查询条件分解、分类，并尽量在SQL语句的最里层进行限定，以减少数据的处理量。
7. 应绝对避免在order by子句中使用表达式。
8. 如果需要从关联表读数据，关联的表一般不要超过7个。
9. 小心使用 IN 和 OR，需要注意In集合中的数据量。建议集合中的数据不超过200个。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，这样可以有效的利用索引。
11. 在查询时尽量减少对多余数据的读取包括多余的列与多余的行。
12. 对于复合索引要注意，例如在建立复合索引时列的顺序是F1，F2，F3，则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致，且必须包含第一列。只能是F1或F1，F2或F1，F2，F3。否则不会用到该索引。
13. 多表关联查询时，写法必须遵循以下原则，这样做有利于建立索引，提高查询效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值条件（=）) and (table1的非等值条件) and (table2与table1的关联条件) and (table2的等值条件) and (table2的非等值条件) and (table3与table2的关联条件) and (table3的等值条件) and (table3的非等值条件)。
注:关于多表查询时from 后面表的出现顺序对效率的影响还有待研究。
14. 子查询问题。对于能用连接方式或者视图方式实现的功能，不要用子查询。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。应该用如下语句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免对列的四则运算，特别是where 条件的左边，严禁使用运算与函数对列进行处理。比如有些地方 substring 可以用like代替。
16. 如果在语句中有not in（in）操作，应考虑用not exists（exists）来重写,最好的办法是使用外连接实现。
17. 对一个业务过程的处理，应该使事物的开始与结束之间的时间间隔越短越好，原则上做到数据库的读操作在前面完成，数据库写操作在后面完成，避免交叉。
18. 请小心不要对过多的列使用列函数和order by,group by等，谨慎使用disti软件开发t。
19. 用union all 代替 union，数据库执行union操作，首先先分别执行union两端的查询，将其放在临时表中，然后在对其进行排序，过滤重复的记录。
当已知的业务逻辑决定query A和query B中不会有重复记录时，应该用union all代替union，以提高查询效率。
Ⅳ SQL查询和实体查询那个查询效率高
你说的实体查询是什么意思？ORM那些东西吗？
如果是，那么还是sql的效率高，很简单，因为实体最终还是要转化为sql去查询。使用orm的意义，不在于提高你的执行效率，而在于提高你的开发效率，是要把非面向对象的sql操作，转化为面向对象的实体操作。
Ⅵ 为什么存储过程比sql语句效率高
1 存储过程允许标准组件式编程
存储过程在被创建以后可以在程序中被多次调用而不必重新编写该存储过程的sql
语句而且数据库专业人员可随时对存储过程进行修改但对应用程序源代码毫无影响因
为应用程序源代码只包含存储过程的调用语句从而极大地提高了程序的可移植性
2 存储过程能够实现较快的执行速度
如果某一操作包含大量的transaction-sql 代码或分别被多次执行那么存储过程要
比批处理的执行速度快很多因为存储过程是预编译的在首次运行一个存储过程时查询优化器对其进行分析优化并给出最终被存在系统表中的执行计划而批处理的transaction-
sql 语句在每次运行时都要进行编译和优化因此速度相对要慢一些
3 存储过程能够减少网络流量
对于同一个针对数据数据库对象的操作如查询修改如果这一操作所涉及到的
transaction-sql 语句被组织成一存储过程那么当在客户计算机上调用该存储过程时
网络中传送的只是该调用语句否则将是多条sql 语句从而大大增加了网络流量降
低网络负载
4 存储过程可被作为一种安全机制来充分利用
系统管理员通过对执行某一存储过程的权限进行限制从而能够实现对相应的数据访
问权限的限制避免非授权用户对数据的访问保证数据的安全
Ⅶ LINQ比一般的SQL语句效率更高吗
Linq是一个范围比较大的概念，它其中不单单只有linq to sql，还有相应的linq to xml等等。所以拿linq 与SQL语句相比，没有可比性的。
但如果拿linq to sql相比的话，与SQL还是有很大的可比性的。一般情况下，你必须要明白你所指的效率是哪一方面？是数据库执行效率？还是整体成品软件运行效率？还是开发效率？
开发效率上linq to sql显然要比SQL的效率要高很多，我们使用linq to sql 可以很容易实现编程，其中的代码量也大大减少。所以如果从开发方面linq to sql的效率是毫无疑问要高于直接的SQL与数据库连接。
如果从编方译考虑，这个一般情况下，linq to sql是引入的新的技术，效率肯定是不如SQL的。好在这个编译的部分不需要开发人员或是任何用户的参与，所以即是效率差一点，对软件来说没有任何的影响。
最后一部分你可以比较感兴趣，谁对数据库的连接更快，执行效率更好？答案是linq to sql而不是直接的语句。一般我们使用直接的语句要求的是即是的执行，但事实上很多时间我们根本不需要那么多，linq to sql其实说明了就是会自动生成与表结构同样的一些对象。而这些对象在联系数据库时也是直接编译好的语句，直接联系时，两者效率是相同的。
但是，如果我们对数据进行处理时，你就会发现，linq to sql的效率为什么会更高了！因为他在读取时不但会读取当前表来填充生成的对象，同时还是延时读其相关表，为你使用有关系的表提供了极大的方便。那么你的相关表的读取效率要快了！
但不管怎么样，他们都是在站立在了ado.net的基础之上的，只不过有些自动生成了，根本不需要你再去做而已。唯一效果比较差的是，linq to sql读出的数据在系统中被转化了，同时它效率虽然变差一些，但是却带来了另一个好处，就是我们常说的SQL注入问题不再出现，你所输入的任何东西都会变成了字符串了。
其实ADO.net的方案中我们使用了datareader方案的效高是比较高的，但是对于更新却是极差的。而使用数据适配器的方案效率较底一些，更对于数据的更新是相当好的，而对于linq to sql其实它是使用数据缓存方案，也就是说linq to sql其实将数据库中的数据缓存到了对象中，如果对象发生了更改，有必须过行返馈时，它是可以进行反馈的，而是这种反馈是可控制的，事务性的。从各方面给我们带来了好处。
我们可以在更新了很多内容之后再去提交更改，那么这种效率论从理解上还是效率上都优化你的原来的语句的！所以linq to sql并非在性能上的降低，而是一种提高。
严格说来，linq to sql并不是节省了代码，相反它增加了很多代码，便幸运的是，这些代码都是由linq to sql框架自动生成的。若是换作人工，容易出错的。但在使用时，由于框架完成了大部分的代码，我们再使用linq to sql加上lambad表达式或查询表达式，我们的代码就变得极少且极简洁了！而如果使用lambad表达式或查询表达式时，它的效率显然不如直接SQL来的直接。读取效率会变得差一些的！
这是因为lambda表达式或查询表达式是一个动态编译的效果，而不是直接编译好的，他要对语句进行编译与优化以何证效率，但性能上因为多了一重处理，效率没有SQL来的直接。但一般情况下，使用linq to sql配合查询表达式或lambad表达式时，效率虽然稍差，但是带来的却是代码的简洁与易理解性，如果不配合查询表达式与lambad表达式，linq to sql的优劣还不利用体现。所以关非linq to sql的效率差，而是我们使用了查询表达式的动态编译导致了效率较差。就linq to sql本身上来就，效率并不差的！
Ⅷ 关于sql优化是什么意思
就是你的sql查询效率太低，需要优化。使其查询效率高，处理时间段。
比如，修改查询条件。select * 和 select 字段1，字段2，处理时间不一致的。
再比如， where条件， where to_char(date,'yyyy/mm/dd') = '2018/03/19' 和 where date = to_date('2018/03/19' ,'yyyy/mm/dd')
数据多，会有很大的差别。上100w，1000w，亿的数据
Ⅸ 同样的SQL语句在SQL2000中的执行效率反而大大高于SQL2008，不解！
呵呵,要看在什么情况下做的.如果你本来就是sql 2000的语句,以前在sql 2000上运行过,那么很正常的.sql server 对于陌生语句的执行是要花很多时间,可是如果你重复运行看看.那个时间叫一个短啊...
另外也要看索引是什么样子的?如果sql 2000上存在索引,而2008上没有索引.那么你得到的结论很正常的.
最后这种问题其实没有必要问,mssql 开发组的人都不是sb,他们不会把sql 2008做的比2000还差.还有就是2000和20008完全就不是同一个核心.你;连2005都没用,就直接跳跃到2008,太牛了.
Ⅹ sql语句联合查询 与 视图想比较的话，那个效率快，为什么。
sql效率比较快，存储过程的好处是不仅快且更安全，但移植性差。视图可以封装查询的复杂性，就像面向对象里类的概念一样。