sql高效

⑴ 如何书写高效的sql语句

优化SQL查询：如何写出高性能SQL语句
1、首先要搞明白什么叫执行计划？
执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生欀如一条SQL语句如果用来从一个10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用 “全表扫描”方式。
可见，执行计划并不是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要：
(1) SQL语句是否清晰地告诉查询优化器它想干什么？
(2) 查询优化器得到的数据库统计信息是否是最新的、正确的？
2、统一SQL语句的写法
对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。
select * from al
select * From al
其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划。
所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！
3、不要把SQL语句写得太复杂
我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的。我拿着这2页长的SQL语句去请教原作者，结果他说时间太长，他一时也看不懂了。可想而知，连原作者都有可能看糊涂的SQL语句，数据库也一样会看糊涂。
一般，将一个Select语句的结果作为子集，然后从该子集中再进行查询，这种一层嵌套语句还是比较常见的，但是根据经验，超过3层嵌套，查询优化器就很容易给出错误的执行计划。因为它被绕晕了。像这种类似人工智能的东西，终究比人的分辨力要差些，如果人都看晕了，我可以保证数据库也会晕的。
另外，执行计划是可以被重用的，越简单的SQL语句被重用的可能性越高。而复杂的SQL语句只要有一个字符发生变化就必须重新解析，然后再把这一大堆垃圾塞在内存里。可想而知，数据库的效率会何等低下。
4、使用“临时表”暂存中间结果
简化SQL语句的重要方法就是采用临时表暂存中间结果，但是，临时表的好处远远不止这些，将临时结果暂存在临时表，后面的查询就在tempdb中了，这可以避免程序中多次扫描主表，也大大减少了程序执行中“共享锁”阻塞“更新锁”，减少了阻塞，提高了并发性能。
5、 OLTP系统SQL语句必须采用绑定变量
select * from orderheader where changetime > ’2010-10-20 00:00:01′
select * from orderheader where changetime > ’2010-09-22 00:00:01′
以上两句语句，查询优化器认为是不同的SQL语句，需要解析两次。
如果采用绑定变量
select * from orderheader where changetime > @chgtime
@chgtime变量可以传入任何值，这样大量的类似查询可以重用该执行计划了，这可以大大降低数据库解析SQL语句的负担。一次解析，多次重用，是提高数据库效率的原则。
6、绑定变量窥测

⑵ SQL如何建立高效能索引

字段1上应该是有默认的索引的,这样的话简单的看应该在字段4上创建索引,来提高查询和删除的效率,但具体的需要看的查询类型,比如你要是等值查询,可以用B+树索引或HASH索引,而如果查询是范围查询则只能是B+树索引,HASH索引不支持范围查询.此外,如果是LIKE查询,则可能使用不了查询,因为现在还没有索引能够支持统配符.
再有就是你的查询选择度是什么情况, 如果字段4上有索引,再在字段2上建索引的查询效率可能不确定

⑶ SQL 查询语句高效 的

select

b.queid,
b.quename,
b.treeid,
a2.treename
from
a a1,b,a a2
where
a1.typenum = 1001
and
a1.treeid = b.treeid
and
a1.parentid = a2.treeid

⑷ 查询的SQL语句怎么写才能提高查询效率

这是SQL语句优化的问题了。网上好多类似的文章，非常全面。
个人觉得比较常用的是：
SQL语句查询中经常用到的字段建索引，这样可以非常明显的提升查询速度。
FROM表的顺序，大表在前，小表在后，因为检索的顺序从后往前。
WHERE， WHERE A.COLUMN = B.COLUMN，把小表的字段放在后边（B表），大表在前。
固定值查询的放在后边 COLUMN = '1'这种。因为这个也是从后往前的顺序。
如果有(NOT) IN (SELECT ...) 尽量避免，因为IN里面也是一个大的查询，使用 (NOT) EXISTS的语法代替。
还有UNION和UNION ALL，多表联合，UNION的作用是可以去掉重复，如果多表没有重复数据，使用UNION ALL效率也会大大提高。

⑸ 如何提高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的一个参数，这个参数控制着在评估一个查询的时候，基于消耗的优化器所评估的可能合并数量。

(5)sql高效扩展阅读：

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

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

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

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

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

⑹ 如何判断一条sql语句是否高效，也就是得出它

oracle存储过程判断一条sql语句是否成功的方法是增加exception处理，如果没有抛出exception，那就证明正常执行了。
在Oracle中，异常分为以下两类：
Oracle预定义异常
用户自定义异常

⑺ 如何编写一个高效的sql语句

少用一些敏感的函数，少连接表，连接表的时候使用exists代替in，not exists代替not in。sql要大写。在条件中能够处理掉较多数据的放最后面。等等。

⑻ 怎样写出精炼高效的sql语句

精炼又高效率的Sql语句对一个大型网站或大型数据库来讲是很有用的，Sql的冗余造成系统与资源的占用和时间的增加。
1.什么样的sql，才算是高效的sql呢？2.sql为什么不走索引？如何让sql走索引，即改变sql的执行计划3.索引有哪几种？4，什时候用索引，什么时候全表扫描oracle优化器的表统计信息，评估出表的最佳连接顺序，表的连接方法，执行路径；最后生成执行计划，oracle就按着这个计划来执行sql1.什么样的sql是高效sql？答：最本质答案就是执行时间最短，怎么才能最短了，就是用最少的资源把事办了，不做无用功；即使sql的io最少，那怎么样才才能最少呢？就是尽量用索引，不要全表扫描；在多表关联的时候，开发人选正确的表连接方法，执行路径等2.sql为何不走索引A.类型不匹配B。条件列包含函数但没有创建相应的函数索引C。复合索引中的前导列没有被做为查询条件D。CBO的模式下，选择的行数比例较大，优化器选择全表扫描E。CBO的模式下，表很久没有分析，优化器选择了全表扫描3.索引种类及创建方法A。B*索引create index indexname on tablename(columnname);B.反向索引create index indexname on tablename(columnname) reverse;C.降序索引create index indexname on tablename(columnname desc);D.位图索引create bitmap index indexname on tablename(columnname);E。函数索引create index indexname on tablename(functionname(columnname));4，什时候用索引，什么时候用全表扫描？答：要使用索引时，首先要弄清一些基本信息表有多少行?查询返回多少行？表的哪些列上有索引？都是什么样的索引？在有多个条件列时，应该选择什么样的索引？A.当查询的记录数，在有序表中小于40%的时候，最好用索引；否则用全表扫描B.当查询的记录数，在有无序表中小于7%的时候，最好用索引；否则用全表扫描C.表的锁片较多时（这个表dml操作很频繁）

⑼ 高效地进行sql语句设计遵循哪些方面

1、尽量少用IN操作符，基本上所有的IN操作符都可以用EXISTS代替。不用NOT IN操作符，可以用NOT EXISTS或者外连接+替代。
2、不用“<>”或者“!=”操作符。对不等于操作符的处理会造成全表扫描，可以用“<” or “>”代替。
3、Where子句中出现IS NULL或者IS NOT NULL时，Oracle会停止使用索引而执行全表扫描。可以考虑在设计表时，对索引列设置为NOT NULL。这样就可以用其他操作来取代判断NULL的操作。
4、当通配符“%”或者“_”作为查询字符串的第一个字符时，索引不会被使用。
5、对于有连接的列“||”，最后一个连接列索引会无效。尽量避免连接，可以分开连接或者使用不作用在列上的函数替代。
6、如果索引不是基于函数的，那么当在Where子句中对索引列使用函数时，索引不再起作用。Where子句中避免在索引列上使用计算，否则将导致索引失效而进行全表扫描。
7、对数据类型不同的列进行比较时，会使索引失效。
8、用“>=”替代“>”。
9、UNION操作符会对结果进行筛选，消除重复，数据量大的情况下可能会引起磁盘排序。如果不需要删除重复记录，应该使用UNION ALL。
10、Oracle从下到上处理Where子句中多个查询条件，所以表连接语句应写在其他Where条件前，可以过滤掉最大数量记录的条件必须写在Where子句的末尾。
11、Oracle从右到左处理From子句中的表名，所以在From子句中包含多个表的情况下，将记录最少的表放在最后。（只在采用RBO优化时有效）
12、Order By语句中的非索引列会降低性能，可以通过添加索引的方式处理。严格控制在Order By语句中使用表达式。
13、不同区域出现的相同的Sql语句，要保证查询字符完全相同，以利用SGA共享池，防止相同的Sql语句被多次分析。
14、多利用内部函数提高Sql效率。例如DECODE
15、当在Sql语句中连接多个表时，使用表的别名，并将之作为每列的前缀。这样可以减少解析时间。
需要注意的是，随着Oracle的升级，查询优化器会自动对Sql语句进行优化，某些限制可能在新版本的Oracle下不再是问题。尤其是采用CBO（Cost-Based Optimization，基于代价的优化方式）时。

⑽ 如何使 SQL Server高效

从功能上来讲，主键是对表中数据的一种约束（唯一、不允许NULL值），我们通过唯一索引（或约束），并且在字段上设置 NOT NULL属性可以达到同样的效果。所以玉键是可以被取代的，这也说明它不是必需的了（当然，就算没有等同的可取代的功能，从业务上来讲，也并不是每个表都要有一个能够确保数据唯一的东东）。
在提主键的时候，会提聚焦索引，主要是因为主键默认是聚焦索引（如果表中原来没有聚焦索引，并且没有指定NONCLUSTERED的情况下），这表明主键并不是聚焦索引，只是可以把它设置为聚焦索引
所以，单独讨论自增列做主键没有任何意义，我们增加一个自增列，并且把它确认它是唯一和非NULL值的，对于我们的业务数据而言，不存在任何意义（多余和没有必要）。
需要考虑的，是主键作为聚焦索引的情况，当主键为聚焦索引时，我们要考虑的，除了主键的特性外，还要考虑聚焦索引的特性。聚焦索引是和数据存储在一起的，它决定数据的存储顺序，表中数据存储的非叶子层是聚焦索引值（叶子层是数据）；另外，聚焦索引键是非聚焦索引的行定位器（指向数据记录的指针，如果聚集索引不是唯一的索引，SQL Server 将添加在内部生成的值（称为唯一值）以使所有重复键唯一。此四字节的值对于用户不可见。仅当需要使聚集键唯一以用于非聚集索引中时，才添加该值）。如果表中没有聚焦索引，那么非聚焦索引的行定位器是指向行的指针（由文件标识符 (ID)、页码和页上的行数生成的行 ID (RID)）。很显然，非聚焦索引不依赖聚焦索引，而数据存储我们也并不一定需要保证按照某个顺序来存储，所以聚焦索引也不是必需的。但是从效率上来讲，顺序读取比行ID这种无序读取更有效率，所以对于频繁查询的表，聚焦索引是需要的。