sql语句计算总金额？SQL Server数据库的高性能优化经验总结
SQL Server数据库的高性能优化经验总结
本文主要向人们介绍的是正确优化SQL
Server数据库的经验总结，其中包括在对其进行优化的实际操作中值得大家留意的地方描述，以及对SQL语句进行优化的最基本原则，以下就是文章的主要内容描述。
优化数据库要留意的事项：
1、关键字段建立索引。
2、使用存储过程，它使SQL变得更加灵活和高效。
3、备份数据库和清除垃圾数据。
4、SQL语句语法的优化。(可以用Sybase的SQL
Expert，可惜我没找到unexpired的序列号)
5、清理删除日志。
SQL语句优化的基本原则：
1、使用索引来更快地遍历表。
缺省情况下建立的索引是非群集索引，但有时它并非最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。
正常来说：
①.有大量重复值、且常常有范围查询(between,
>,<
，>=,<
=)和order
by、group
by发生的列，可考虑建立群集索引
②.常常同时存取多列，且每列都含有重复值可考虑建立组合索引;
③.组合索引要尽可能使关键查询形成索引覆盖，其前导列一定是使用最频频的列。
2、IS
NULL
与
IS
NOT
NULL
不可以用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。亦就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在where子句中使用is
null或is
not
null的语句优化器是不允许使用索引的。
3、IN和EXISTS
EXISTS要远比IN的效率高。里面关系到full
table
scan和range
scan。几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。
4、在海量查询时尽可能少用格式转换。
5、当在SQL
SERVER
2000中
如果存储过程只有一个参数，并且是OUTPUT类型的，必须要在调用这一个存储过程的时候给这一个参数一个初始的值，否则就会出现调用错误。
6、ORDER
BY和GROPU
BY
使用ORDER
BY和GROUP
BY短语，任何一种索引都有助于SELECT的性能提高。留意如果索引列里面有NULL值，Optimizer将无法优化。
7、任何对列的操作都将导致表扫描，它包括SQL
Server数据库函数、计算表达式等等，查询时要尽最大可能将操作移至等号右边。
8、IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可考虑把子句拆开。拆开的子句中应包含索引。
9、SET
SHOWPLAN_ALL>10、谨慎使用游标
在某些必须使用游标的场合，可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行操作，这样可使性能得到明显提高。
注释：所谓的优化就是WHERE子句利用了索引，不可优化即发生了表扫描或额外开销。经验显示，SQL
Server数据库性能的最大改进得益于逻辑的数据库设计、索引设计和查询设计方面。反过来说，最大的性能问题常常是由其中这些相同方面中的不足引起的。
其实SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽可能避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及SQL
Server数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。
ORACLE优化SQL语句,提高效率(2)
索引是表的一个概念部分用来提高检索数据的效率 Oracle使用了一个复杂的自平衡B tree结构通常通过索引查询数据比全表扫描要快当 Oracle找出执行查询和Update语句的最好路径时 Oracle优化器将使用索引同样在联结多个表时使用索引也能提高效率另外一个使用索引的好处是他提供了主键(primary key)的唯一性验证那些LONG或LONG RAW数据类型您可以索引几乎任何的列通常在大型表中使用索引特别有效当然您也会发现在扫描小表时使用索引同样能提高效率虽然使用索引能得到查询效率的提高但是我们也必须留意到他的代价索引需要空间来存储也需要定期维护每当有记录在表中增减或索引列被撰改时索引本身也会被撰改这就意味着每条记录的INSERT DELETE UPDATE将为此多付出次的磁盘I/O因为索引需要额外的存储空间和处理那些不必要的索引反而会使查询反应时间变慢定期的重构索引是很有必要的
ALTER INDEX<INDEXNAME> REBUILD<TABLESPACENAME>
（）用EXISTS替换DISTINCT
当提交一个包含一对多表信息(例如部门表和雇员表)的查询时避免在SELECT子句中使用DISTINCT一般可以考虑用EXIST替换 EXISTS使查询更为迅速因为RDBMS核心模块将在子查询的条件一旦满足后立即返回结果例子
(低效): SELECT DISTINCT DEPT_NO DEPT_NAME FROM DEPT D EMP E WHERE D DEPT_NO= E DEPT_NO(高效): SELECT DEPT_NO DEPT_NAME FROM DEPT D WHERE EXISTS( SELECT X FROM EMP E WHERE E DEPT_NO= D DEPT_NO);
（）SQL语句用大写的因为Oracle总是先解析SQL语句把小写的字母转换成大写的再执行
（）在Java代码中尽可能少用连接符＋连接字符串
（）避免在索引列上使用NOT通常我们需要避免在索引列上使用NOT NOT会产生在和在索引列上使用函数相同的影响当Oracle碰到 NOT他就会停止使用索引转而执行全表扫描
（）避免在索引列上使用计算 WHERE子句中假如索引列是函数的一小部分优化器将不使用索引而使用全表扫描
举例:
低效 SELECT… FROM DEPT WHERE SAL*>;高效: SELECT… FROM DEPT WHERE SAL>/;
（）用>=替代>
高效 SELECT* FROM EMP WHERE DEPTNO>=低效: SELECT* FROM EMP WHERE DEPTNO>
两者的区别在于前者DBMS将会直接跳到第一个DEPT等于的记录而后者将首先定位到DEPTNO=的记录并且向前扫描到第一个DEPT大于的记录
（）用UNION替换OR(适用于索引列)
正常情况下用UNION替换WHERE子句中的OR将会起到较好的效果对索引列使用OR将造成全表扫描留意以上规则只针对多个索引列有效假如果有column没有被索引查询效率也许会因为您没有选择OR而降低在下面的例子中 LOC_ID和REGION上都建有索引
高效 SELECT LOC_ID LOC_DESC REGION FROM LOCATION WHERE LOC_ID= UNION SELECT LOC_ID LOC_DESC REGION FROM LOCATION WHERE REGION= MELBOURNE
低效: SELECT LOC_ID LOC_DESC REGION FROM LOCATION WHERE LOC_ID= OR REGION= MELBOURNE
（）用IN来替换OR
这是一条简单易记的规则但是实际的执行效果还须检验在Oracle i下两者的执行路径似乎是相同的:
低效:
SELECT… FROM LOCATION WHERE LOC_ID= OR LOC_ID= OR LOC_ID=
高效
SELECT… FROM LOCATION WHERE LOC_IN IN();
（）避免在索引列上使用IS NULL和IS NOT NULL
避免在索引中使用任何能为空的列 Oracle将无法使用该索引对于单列索引假如列包含空值索引中将不存在此记录对于复合索引假如每个列都为空索引中同样不存在此记录假如至少有一个列不为空则记录存在于索引中举例假如唯一性索引建立在表的A列和B列上并且表中存在一条记录的 A B值为( null) Oracle将不接受下一条具备相同A B值（ null）的记录(插入)然而假如任何的索引列都为空 Oracle将认为整个键值为空而空不等于空因此您可以插入条具备相同键值的记录当然他们都是空!因为空值不存在于索引列中所以WHERE子句中对索引列进行空值比较将使ORACLE停用该索引
低效:(索引失效)
SELECT… FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;
高效(索引有效)
SELECT… FROM DEPARTMENT WHERE DEPT_CODE>=;
（）总是使用索引的第一个列
假如索引是建立在多个列上只有在他的第一个列(leading column)被where子句引用时优化器才会选择使用该索引这亦是一条简单而重要的规则当仅引用索引的第二个列时优化器使用了全表扫描而忽略了索引
（）用UNION ALL替换UNION(假如果有大可能的话)
当SQL语句需要UNION两个查询结果集合时这两个结果集合会以UNION ALL的方式被合并然后在输出最终结果前进行排序假如用 UNION ALL替代UNION这样排序就不是必要了效率就会因此得到提高需要留意的是 UNION ALL将重复输出两个结果集合中相同记录因此各位还是要从业务需求分析使用UNION ALL的可行性 UNION将对结果集合排序这一个操作会使用到SORT_AREA_SIZE这块内存对于这块内存的优化亦是极为重要的下面的SQL可以用来查询排序的消耗量
lishixinzhi/Article/program/Oracle/201311/16789
