提高SQL效率的方案
--oracle优化slq语句
（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. 回滚段上用于恢复数据的信息。
�
相关文档：
SQL语句的添加、删除、修改虽然有如下很多种方法，但在使用过程中还是不够用，不知是否有高手把更多灵活的使用方法贡献出来？
添加、删除、修改使用db.Execute(Sql)命令执行操作
╔----------------╗
☆ 数据记录筛选 ☆
╚----------------╝
注意：单双引号的用法可能有误(没有测式)
Sql = "S ......
原文地址：http://topic.csdn.net/u/20100203/17
/8F916471-597D-481A-B170-83BCEFE3B199.html
============================我是分割
符================================
应一个朋友的要求，贴上收藏的SQL常用分页的办法～～
表中主键必须为标识列
，[ID] int IDENTITY (1,1)
1.分页方案一：(利用Not In和SELECT ......
DATEDIFF(参数一,参数二,参数三) ---参数一：year month day; 参数二：比较的起始日期,默认1900-1-1；参数三：比较的日期。
eg:DATEDIFF(year,0,getdate())表示比较0（默认1900-1-1）到当前的日期想差几年
SELECT DATEADD(mm, DATEDIFF(mm,0,getdate()), 0) -- 取得本月的第一天
SELECT DATEADD(wk, D ......
1:replace 函数
第一个参数你的字符串，第二个参数你想替换的部分，第三个参数你要替换成什么
select replace('lihan','a','b')
&nb ......
郑重声明一下，这篇日志是我Copy的，不是自己写的，我还没那么强！(仔细看一下，有用。)
关于SQL语句中的双引号、单引号：
（1）先来看一个最简单的SQL语句
Insert Into users(username) values("小王")
大家来� ......
