1、数据库空间是个概述，在sqlserver里，使用语句 exec sp_spaceused 'TableName' 这个语句来查。
Ⅱ 关于SQL数据库优化
具体要注意的：
1.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。
3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
4.in 和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
5.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。
见如下例子：
SELECT * FROM T1 WHERE NAME LIKE ‘%L%’
SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’
SELECT * FROM T1 WHERE NAME LIKE ‘L%’
即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。
6.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
SELECT * FROM T1 WHERE F1/2=100
应改为:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’
应改为:
SELECT * FROM RECORD WHERE CARD_NO LIKE ‘5378%’
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21
应改为:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
10.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
11.很多时候用 exists是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select top 1 from b where num=a.num)
SELECT SUM(T1.C1)FROM T1 WHERE(
(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)
SELECT SUM(T1.C1) FROM T1WHERE EXISTS(
SELECT * FROM T2 WHERE T2.C2=T1.C2)
两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。
如果你想校验表里是否存在某条纪录，不要用count(*)那样效率很低，而且浪费服务器资源。可以用EXISTS代替。如：
IF (SELECT COUNT(*) FROM table_name WHERE column_name = 'xxx')
可以写成：
IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx')
经常需要写一个T_SQL语句比较一个父结果集和子结果集，从而找到是否存在在父结果集中有而在子结果集中没有的记录，如：
SELECT a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl用别名a代替
WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key)
SELECT a.hdr_key FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL
SELECT hdr_key FROM hdr_tbl
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)
三种写法都可以得到同样正确的结果，但是效率依次降低。
12.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
13.避免频繁创建和删除临时表，以减少系统表资源的消耗。
14.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
15.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
16.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
17.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
18.尽量避免大事务操作，提高系统并发能力。
19.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
20. 避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:
SELECT name FROM employee WHERE salary > 60000
在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。
21.充分利用连接条件，在某种情况下，两个表之间可能不只一个的连接条件，这时在 WHERE 子句中将连接条件完整的写上，有可能大大提高查询速度。
例：
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO
第二句将比第一句执行快得多。
22、使用视图加速查询
把表的一个子集进行排序并创建视图，有时能加速查询。它有助于避免多重排序 操作，而且在其他方面还能简化优化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
ORDER BY cust.name
如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个视图中，并按客户的名字进行排序：
CREATE VIEW DBO.V_CUST_RCVLBES
AS
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
然后以下面的方式在视图中查询：
SELECT ＊ FROM V_CUST_RCVLBES
WHERE postcode>“98000”
视图中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。
23、能用DISTINCT的就不用GROUP BY
SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID
可改为：
SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10
24.能用UNION ALL就不要用UNION
UNION ALL不执行SELECT DISTINCT函数，这样就会减少很多不必要的资源
35.尽量不要用SELECT INTO语句。
SELECT INOT 语句会导致表锁定，阻止其他用户访问该表。
上面我们提到的是一些基本的提高查询速度的注意事项,但是在更多的情况下,往往需要反复试验比较不同的语句以得到最佳方案。最好的方法当然是测试，看实现相同功能的SQL语句哪个执行时间最少，但是数据库中如果数据量很少，是比较不出来的，这时可以用查看执行计划，即：把实现相同功能的多条SQL语句考到查询分析器，按CTRL+L看查所利用的索引，表扫描次数（这两个对性能影响最大），总体上看询成本百分比即可。
今天在itput上看了一篇文章，是讨论一个语句的优化：
原贴地址： http://www.itpub.net/viewthread.php?tid=1015964&extra=&page=1
一，发现问题 优化的语句：
请问以下语句如何优化:
CREATE TABLE aa_001
( ip VARCHAR2(28),
name VARCHAR2(10),
password VARCHAR2(30) )
select * from aa_001 where ip in (1,2,3) order by name desc;
--目前表中记录有一千多万条左右，而且in中的值个数是不确定的。
以上就是优化的需要优化的语句和情况。
不少人在后面跟帖：有的说没办法优化，有的说将ＩＮ该为ＥＸＩＳＴＳ，有的说在ip上建立索引复合索引（ip，name)等等。
二，提出问题 那这样的情况，能优化吗，如何优化？今天就来讨论这个问题。
三，分析问题 1，数据量1千万多条。
2，in中的值个数是不确定
3.1 分析数据分布 这里作者没有提到ip列的数据的分布情况，目前ip列的数据分布可能有以下几种：
1，ip列（数据唯一，或者数据重复的概率很小）
2，ip列 (数据不均匀，可能有些数据重复多，有些重复少）
3，ip列 （数据分布比较均匀，数据大量重复，主要就是一些同样的数据（可能只有上万级别不同的ip数据等)
解决问题：
1，对于第一种数据分布情况，只要在ip列建立一个索引即可。这时不管表有多少行， in个数是不确定的情况下，都很快。
2，对应第二中数据分布情况，在ip列建立索引，效果不好。因为数据分布不均匀，可能有些快，有些慢
3，对应第三种数据分布情况，在ip列建立索引，速度肯定慢。
注意：这里的 order by name desc 是在取出数据后再排序的。而不是取数据前排序
对于2，3两个情况，因为都是可能需要取出大量的数据，优化器就采用表扫描(table scan)，而不是索引查找(index seek) ,速度很慢，因为这时表扫描效率要优于索引查找，特别是高并发情况下，效率很低。
那对应2，3中情况，如何处理。是将in改成exists。其实在sql server 2005和oracle里的优化器在in后面数据少时，效率是一样的。这时采用一般的索引效率很低。这时如果在ip列上建立聚集索引，效率会比较高。我们在SQL server 2005中做个测试。
表：[dbo].[[zping.com]]]中有约200万条数据。包含列Userid, id, Ruleid等列。按照上面的情况查询一下类似语句：
select * from [dbo].[[zping.com]]] where
userid in ('',''
,'') order by Ruleid desc
我们先看userid的数据分布情况，执行下面语句：
select userid,count(*) from [dbo].[[zping.com]]] group by userid order by 2
这时我们看看数据分布：总共有379条数据，数据两从1到15万都有，数据分布倾斜严重。下图是其中一部分。
这时如果在ip上建立非聚集索引，效率很低，而且就是强行索引扫描，效率也很低，会发现IO次数比表扫描还高。这时只能在ip上建立聚集索引。这时看看结果。
这时发现，搜索采用了（clustered index seek）聚集搜索扫描。
在看看查询返回的结果：
(156603 行受影响)
表 '[zping.com]'。扫描计数 8，逻辑读取 5877 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
返回15万行，才不到6千次IO。效率较高，因为这15万行要排序，查询成本里排序占了51%。当然可以建立（userid，Ruleid）复合聚集索引，提高性能，但这样做DML维护成本较高。建议不采用。
从上面的测试例子可以看出， 优化的解决办法：
数据分布为1：建立ip索引即可
数据分布为2，3：在ip列建立聚集索引。
Ⅲ 如何优化用SQL语句INSERT INTO
如何优化用SQL语句INSERT INTO
T-SQL脚本优化技巧：
1）对于SELECT/UPDATE语句必须显示的定义所有的列,避免使用星号。
2）在执行SELECT/INSERT/UPDATE/DELETE语句时,请考虑执行规划的重用,尽量考虑用SP-EXECUTESQL存储过程。
3）优先使用 SELECT...INTO，然后使用 INSERT...SELECT，以避免大量死锁。
4）如果需要删除所有的数据,用TRUNCATE TABLE 代替DELETE 。
5）避免使用DISTINCT 语句。
6）如果你需要有限的记录,通过TOP N代替SET ROWCOUNT来控制排序取值。
7）避免使用SARGABLE的语句在WHERE子句,比如: OR, <>, !=, !<, >!, IS NULL, NOT, NOT IN, NOT LIKE 和LIKE,因为这些操作很难利用已知的索引。
8）避免使用NOT IN,可以采用IN,EXISTS NOT EXISTS和LEFT JOIN 加空值判断
--NOT EXISTS, 效率最高 SELECT a.hdr_key
FROM hdr_tbl a
WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key) --LEFT JOIN SELECT a.hdr_key
FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key
WHERE b.hdr_key IS NULL --NOT IN ,效率最低 SELECT hdr_key
FROM hdr_tbl
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl) 9）使用EXISTS判断记录是否存在。
--不好的写法: IF (SELECT COUNT(*) FROM table_name WHERE column_name = 'xxx') --正确的写法: IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx') 10）避免在GROUP BY中使用HAVING 语句。
11）GROUP BY的语句要尽量简单,不要进行GROUP BY语句的嵌套,避免在GROUP BY中包含多余的列
考虑在GROUP BY的列,进行ORDER BY排序,特别在多用户的环境下。
12）如果需要在一个包含JOIN的SELECT语句进行GROUP BY,请考虑用子查询代替JOIN. 如果必须使用GROUP BY, GROUP BY 的应该列在同一张表。
13）如果WHERE条件语句有多个AND条件,请确保至少有一个列有索引,如果没有可以建立多列复合INDEX。
14）对于SQL 无法执行自动优化的WHERE条件语句,可以通过HINTS显示的制定INDEX来提高查询的效率。
--可能不好的写法: SELECT * FROM tblTaskProcessesWHERE nextprocess = 1 AND processid IN (8,32,45) --正确的写法: SELECT * FROM tblTaskProcesses (INDEX = IX_ProcessID)WHERE nextprocess = 1 AND processid IN (8,32,45) 15）尽可能避免在WHERE条件语句中使用函数计算。
--不好的写法: WHERE SUBSTRING(firstname,1,1) = 'm' --正确的写法: WHERE firstname like 'm%' 16）在WHERE条件语句中,避免在函数中包列,如果无法避免,请考虑在该列建立INDEX。
Ⅳ 项目中优化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超详细的 SQL 查询语法教程来啦
作为一名测试工程师，工作中在对测试结果进行数据比对的时候，或多或少要和数据库打交道的，要和数据库打交道，那么一些常用的 SQL 查询语法必须要掌握。最近有部分做测试小伙伴表示 SQL 查询不太会，问我有没有 SQL 查询语法这一块的文档可以学习，于是我就整理了这篇超详细的 SQL 查询语法教程，来给大家参考学习！
创建数据库、数据表
学生表字段说明
班级表字段说明
准备数据
使用 where 子句对表中的数据筛选，结果为 true 的行会出现在结果集中
例 1：查询编号大于 3 的学生
例 2：查询编号不大于 4 的学生
例 3：查询姓名不是“关羽”的学生
例 4：查询没被删除的学生
例 5：查询编号大于 3 的女同学
例 6：查询编号小于 4 或没被删除的学生
例 7：查询姓黄的学生
例 8：查询姓黄并且“名”是一个字的学生
例 9：查询姓刘或叫飞的学生
例 10：查询编号是 1 或 3 或 8 的学生
例 11：查询编号为 3 至 8 的学生
例 12：查询编号是 3 至 8 的男生
例 13：查询没有填写身高的学生
例 14：查询填写了身高的学生
例 15：查询填写了身高的男生
为了方便查看数据，可以对数据进行排序
语法：
说明
例 1：查询未删除男生信息，按学号降序
例 2：查询未删除学生信息，按名称升序
例 3：显示所有的学生信息，先按照年龄从大--> 小排序，当年龄相同时 按照身高从高--> 矮排序
为了快速得到统计数据，经常会用到如下 5 个聚合函数
例 1：查询学生总数
例 2：查询女生的编号最大值
例 3：查询未删除的学生最我号
例 4：查询男生的总年龄
例 5：查询未删除女生的编号平均值
根据 gender 字段来分组，gender 字段的全部值有 4 个'男','女','中性','保密'，所以分为了 4 组 当 group by 单独使用时，只显示出每组的第一条记录， 所以 group by 单独使用时的实际意义不大
当数据量过大时，在一页中查看数据是一件非常麻烦的事情，这个时候就需要多数据进行分页，下面来看看 SQL 分页查询
语法
说明
例 1：查询前 3 行男生信息
示例：分页
子查询
子查询分类
标量子查询
查询班级学生的平均年龄
列级子查询
行级子查询
子查询中特定关键字使用
当查询结果的列来源于多张表时，需要将多张表连接成一个大的数据集，再选择合适的列返回，这中情况下就需要使用到连接查询了，下面给大家介绍一下常用的 3 中连接查询语法：
常用的连接查询语法就给大家介绍到这里了，更多的连接查询语法大家可以扩展学习
Ⅵ 查询的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 语句优化
SELECT DISTINCT * --(这个*一定要写具体字段，有助于提高查询速度)
FROM dbo.[dksj],dbo.[pkhlb1]
WHERE dbo.[dksj].证件号码 *= dbo.[pkhlb1].证件号码
AND 证件号码 = '${sfz}'
Ⅷ SQL 语句优化，该怎么处理
（1）选择最有效率的表名顺序(只在基于规则的优化器中有效)：
ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写
在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的
情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询
, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其
他表所引用的表.
（2） WHERE子句中的连接顺序．：
ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必
须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE
子句的末尾.
（3） SELECT子句中避免使用‘ * ‘：
ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过
查询数据字典完成的, 这意味着将耗费更多的时间
（4）减少访问数据库的次数：
ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变
量 , 读数据块等；
（5）在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加
每次数据库访问的检索数据量 ,建议值为200
（6）使用DECODE函数来减少处理时间：
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表.
（7）整合简单,无关联的数据库访问：
如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使
它们之间没有关系)
（8）删除重复记录：
最高效的删除重复记录方法 ( 因为使用了ROWID)例子：
DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)
FROM EMP X WHERE X.EMP_NO = E.EMP_NO);
（9）用TRUNCATE替代DELETE：
当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存
放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前
的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用TRUNCATE时, 回
滚段不再存放任何可被恢复的信息.当命令运行后,数据不能被恢复.因此很少的
资源被调用,执行时间也会很短. (译者按: TRUNCATE只在删除全表适
用,TRUNCATE是DDL不是DML)
（10）尽量多使用COMMIT：
只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求也
会因为COMMIT所释放的资源而减少:
COMMIT所释放的资源:
a. 回滚段上用于恢复数据的信息.
b. 被程序语句获得的锁
c. redo log buffer 中的空间
d. ORACLE为管理上述3种资源中的内部花费
（11）用Where子句替换HAVING子句：
避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行
过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,
那就能减少这方面的开销. (非oracle中)on、where、having这三个都可以加条
件的子句中，on是最先执行，where次之，having最后，因为on是先把不符合条
件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该
速度是最快的，where也应该比having快点的，因为它过滤数据后才进行sum，在
两个表联接时才用on的，所以在一个表的时候，就剩下where跟having比较了。
在这单表查询统计的情况下，如果要过滤的条件没有涉及到要计算字段，那它们
的结果是一样的，只是where可以使用rushmore技术，而having就不能，在速度
上后者要慢如果要涉及到计算的字段，就表示在没计算之前，这个字段的值是不
确定的，根据上篇写的工作流程，where的作用时间是在计算之前就完成的，而
having就是在计算后才起作用的，所以在这种情况下，两者的结果会不同。在多
表联接查询时，on比where更早起作用。系统首先根据各个表之间的联接条件，
把多个表合成一个临时表后，再由where进行过滤，然后再计算，计算完后再由
having进行过滤。由此可见，要想过滤条件起到正确的作用，首先要明白这个条
件应该在什么时候起作用，然后再决定放在那里
（12）减少对表的查询：
在含有子查询的SQL语句中,要特别注意减少对表的查询.例子：
SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECT
TAB_NAME,DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)
（13）通过内部函数提高SQL效率.：
复杂的SQL往往牺牲了执行效率. 能够掌握上面的运用函数解决问题的方法
在实际工作中是非常有意义的
（14）使用表的别名(Alias)：
当在SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每个Column
上.这样一来,就可以减少解析的时间并减少那些由Column歧义引起的语法错误.
（15）用EXISTS替代IN、用NOT EXISTS替代NOT IN：
在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行联
接.在这种情况下, 使用EXISTS(或NOT EXISTS)通常将提高查询的效率. 在子查
询中,NOT IN子句将执行一个内部的排序和合并. 无论在哪种情况下,NOT IN都是
最低效的 (因为它对子查询中的表执行了一个全表遍历). 为了避免使用NOT IN
,我们可以把它改写成外连接(Outer Joins)或NOT EXISTS.
例子：
（高效）SELECT * FROM EMP (基础表) WHERE EMPNO > 0 AND EXISTS (SELECT
‘X' FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = ‘MELB')
(低效)SELECT * FROM EMP (基础表) WHERE EMPNO > 0 AND DEPTNO IN(SELECT
DEPTNO FROM DEPT WHERE LOC = ‘MELB')
（16）识别'低效执行'的SQL语句：
虽然目前各种关于SQL优化的图形化工具层出不穷,但是写出自己的SQL工具
来解决问题始终是一个最好的方法：
SELECT EXECUTIONS , DISK_READS, BUFFER_GETS, ROUND((BUFFER_GETS-
DISK_READS)/BUFFER_GETS,2) Hit_radio, ROUND(DISK_READS/EXECUTIONS,2)
Reads_per_run,
SQL_TEXT FROM V$SQLAREA WHERE EXECUTIONS>0 AND BUFFER_GETS > 0 AND
(BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8 ORDER BY 4 DESC;
（17）用索引提高效率：
索引是表的一个概念部分,用来提高检索数据的效率，ORACLE使用了一个复
杂的自平衡B-tree结构. 通常,通过索引查询数据比全表扫描要快. 当ORACLE找
出执行查询和Update语句的最佳路径时, ORACLE优化器将使用索引. 同样在联结
多个表时使用索引也可以提高效率. 另一个使用索引的好处是,它提供了主键
(primary key)的唯一性验证.。那些LONG或LONG RAW数据类型, 你可以索引几乎
所有的列. 通常, 在大型表中使用索引特别有效. 当然,你也会发现, 在扫描小
表时,使用索引同样能提高效率. 虽然使用索引能得到查询效率的提高,但是我们
也必须注意到它的代价. 索引需要空间来存储,也需要定期维护, 每当有记录在
表中增减或索引列被修改时, 索引本身也会被修改. 这意味着每条记录的INSERT
, DELETE , UPDATE将为此多付出4 , 5 次的磁盘I/O . 因为索引需要额外的存
储空间和处理,那些不必要的索引反而会使查询反应时间变慢.。定期的重构索引
是有必要的.：
ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>
（18）用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);
（19） sql语句用大写的；因为oracle总是先解析sql语句，把小写的字母转换成大写的再执行
（20）在java代码中尽量少用连接符“＋”连接字符串！
Ⅸ sql 语句优化
tbl_pgw_refund_info:refund_req,result
tbl_pgw_refund_dtl :pay_brh_id
tbl_pgw_txn_dtl :order_id
TBL_PGW_TXN_DTL :int_txn_dt,rsp_code
TBL_PGW_PAY_DTL :order_id
在上述表的指定字段上建索引