sql效率

‘壹’ 如何提高sql查询的效率

你的题目太笼统，因为不同的写法，不同的处理方式，不同的数据量，都会有不同的考虑，需要根据实际情况来提升，对于mssql，以下几点可以参考
1、少用子查询
2、少用or，当有or时，可以用union代替
3、查询数据量太大，太慢，并且有子查询时，可以考虑下临时表处理
4、数据量大时，索引是提升效率的好手段
5、需要用到in的条件可以考虑用exists来取代
6、mssql的软件有一个显示计划时间，可以帮助优化sql，就写这么多吧，毕竟优化包含太多了，需要自己一点点的积累，并且不同场景不同处理

‘贰’ sql执行效率

第二个效率高。
理由是sql查询，会先走子查询。数据量在一步步减少。
2个子查询出来的数据会少很多。
第一个是全表关联，所有的数据会有效。
建议：如果实际想知道哪一个快，可以用工具查看执行计划，看看cost的使用量

‘叁’ 关于SQL语句的效率问题

一般说来，对于sex这样的字段，索引不索引都没什么效果，如果知道是boy，最好就别加这个条件。

对于你这样的查询，应该给name建议索引。

对于比较实用的数据库管理系统（DBMS），系统会自动优化。对于比较垃圾的系统，很多时候没办法优化，比如有的数据库只要存在OR就不走索引，那么你上面的语句就没有三次select来得快。

‘肆’ SQL语句效率问题

对比查询性能，不能只看语句，而是要看执行计划。即使是相同的查询语句，在不同的情况下也有可能生成不同的执行计划。

之所以一个查询性能高，是因为id字段上有聚集索引。从查询计划来看，使用了合并连接(merge join)，合并连接是非常高效的连接。
而第二个查询使用了max聚合，聚合运算本身效率比较低，而且因为聚合的使用，使得不能使用合并连接，而只能使用嵌套循环(nested loop)，所以效率低。

‘伍’ sql里面>1和>=2那个效率高点

>=2效率更高

原因是这样的 >1 那数据库每拿到一个数据都要和1进行比较，判断是否小于1
但是>=2的话 数据库只需要记得最小数字是2，其它数字都可以

这样计算更少 所以也更快
PS：
>1和>=2效率是完全不一样的。现在的sql优化器还不是非常智能。

‘陆’ 如何查看sql执行效率

在点击某个按钮,执行完后,再执行下面语句,就可以知道系统运行什么Sql和多少次了,其主要慢语句是那些了;

--先清除sql server的缓存dbcc freeProcCache SELECT creation_time N'语句编译时间' ,last_execution_time N'上次执行时间' ,total_physical_reads N'物理读取总次数' ,total_logical_reads/execution_count N'每次逻辑读次数' ,total_logical_reads N'逻辑读取总次数' ,total_logical_writes N'逻辑写入总次数' ,execution_count N'执行次数' ,total_worker_time/1000 N'所用的CPU总时间ms' ,total_elapsed_time/1000 N'总花费时间ms' ,(total_elapsed_time / execution_count)/1000 N'平均时间ms' ,SUBSTRING(st.text, (qs.statement_start_offset/2) + 1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) N'执行语句'FROM sys.dm_exec_query_stats AS qsCROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) stwhere SUBSTRING(st.text, (qs.statement_start_offset/2) + 1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) not like '%fetch%'ORDER BY total_elapsed_time / execution_count DESC;

‘柒’ SQL效率问题

多次重复执行第二条语句，如果每次都慢，才能说明是第二条语句的固有问题。如果有时快有时慢，说明不是语句的固有问题，是跟数据库负载以及buffer cache中的数据有关系。

如果确认是语句的固有问题，要准备定位15秒的时间究竟是花在哪里，只有做trace这一种方法，其他方法都只是猜测。

做trace的方法网上可以搜到，之后对trace文件用tkprof处理，可以看到15秒都用在了哪里，哪一步花了多少时间，这样就可以准确定位出问题的地方。

如果lz不愿意做trace，那么根据经验，我认为这个问题出在索引选择（与第一条语句选择的索引不同）的可能性第一，出在排序的可能性第二。

有不明白的，可以在明天pm我

补充：
什么都不做就想知道问题具体是怎么回事是做不到的
1、执行计划贴出来看一下。
2、tkprof的结果贴出来看一下。
这两者没有，一切都是空谈。

‘捌’ sql语句的效率问题

给这个字段加一个索引就行了

‘玖’ 对比sql语句效率

sql1是老式的联表查询，官方已经是不赞成现在还继续使用这种查询方式，而sql2是官方赞成的联表查询。现在基本上都是 sql2的查询方式，所以在效率方面肯定是新技术胜过旧技术。

‘拾’ 如何提高sql语句的执行效率

1、使用ordered提示

Oracle必须花费大量的时间来剖析多表的合并，用以确定表合并的最佳顺序。SQL表达式涉及七个乃至更多的表合并，那么有时就会需要超过30分钟的时间来剖析，Ordered这个提示(hint)和其他的提示一起使用能够产生合适的合并顺序。

2、使用ordered_predicates

ordered_predicates提示在查询的WHERE子句里指定的，并被用来指定布尔判断(Booleanpredicate)被评估的顺序。在没有ordered_predicates的情况下，Oracle会使用下面这些步骤来评估SQL判断的顺序：子查询的评估先于外层WHERE子句里的Boolean条件。

所有没有内置函数或者子查询的布尔条件都按照其在WHERE子句里相反的顺序进行评估，即最后一条判断最先被评估。每个判断都带有内置函数的布尔判断都依据其预计的评估值按递增排列。

3、限制表格合并评估的数量

提高SQL剖析性能的最后一种方法是强制取代Oracle的一个参数，这个参数控制着在评估一个查询的时候，基于消耗的优化器所评估的可能合并数量。

(10)sql效率扩展阅读：

1、表设计的优化，数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。

2、语句的查询优化，保证在实现功能的基础上，尽量减少对数据库的访问次数；

3、建立高效的索引创建索引一般有以下两个目的：维护被索引列的唯一性和提供快速访问表中数据的策略。

大型数据库有两种索引即簇索引和非簇索引，一个没有簇索引的表是按堆结构存储数据，所有的数据均添加在表的尾部，而建立了簇索引的表，其数据在物理上会按照簇索引键的顺序存储。个表只允许有一个簇索引。

4、强制查询转换，有时候oracle 的优化器未必能走正确的查询路线，这个时候就需要添加一些hint 之类的来规定他的执行路线。当然了，这个未必是最好的处理方案。因为虽然现在走这个路线是对的，以为因为数据的变化到这这个HINT 变得不可取。