SQL编写经验汇总

UNION操作符
这个SQL在运行时先取出两个表的结果，再用排 序空间进行排序删除重复的记录，最后返回结果 集，如果表数据量大的话可能会导致用磁盘进行 排序。 案 ： 采 用 UNION ALL 操 作 符 替 代 推荐方 UNION，因为UNION ALL操作只是简单的将两 个结果合并后就返回。所以在写Union语句时， 如果你能保证各个子语句的查询结果没有重复的 项 ， 就 用 Union all ， 至少 可以 减少 Oracle 的 union运算步骤，语句实例如下： select FOLDERNO from FOLDERS where FLSTS=’OOS-A’ union all select FOLDERNO from where FLDSTS = ‘OOS-A’ 查询表的顺序 FOLDERS_OLD
尽量在SQL语句的Where条件中应用到数据库表的索引
在编写SQL语句时，努力避免出现“全表扫描 ”，在where条件努力用到数据库的index，提 高SQL语句的性能
如果能不用到in，尽量不要在SQL语句的Where条件中出 虽然用IN写出来的SQL的优点是比较容易，并且 清晰易懂，这比较适合现代软件开发的风格，但 现in 是用IN的SQL性能总是比较低的，从ORACLE 执行的步骤来分析用IN的SQL与不用IN的SQL有 以下区别： ORACLE试图将带有IN的SQL语句转换成多个 表的连接，如果转换不成功则先执行IN里面的子 查询，再查询外层的表记录，如果转换成功则直 接采用多个表的连接方式查询。由此可见用IN的 SQL至少多了一个转换的过程。一般的SQL都可 以转换成功，但对于含有分组统计等方面的SQL 就不能转换了。而语法转换可是最消耗CPU资 源的。 强列推荐不在Where中使用NOT IN，如果万一要用not Not In操作不能应用表的索引，导致出现全表扫 in，只能用NOT EXISTS来取代了，或者用多表联合查询 描。 了。 not exists也不是什么好东东，在使用exists时就 靠天了，如果运气好，exists的条件子语句能用 得上索引的话，性能还不会有太多的影响。 尽量不要在SQL语句的Where条件中出现<>（不等号） <>（不等于）操作符不会用到索引的，导致全 表扫描。 个人建议用相同功能的操作运算来代替，譬如 count <> 100改为count >100 or count < 100 在where语句中，在判断字段是否为空时，尽量不要出现 一般的数据库索引算法都采用的是B树查找算 IS NULL 或 IS NOT NULL ， 用 其 它 等 义 的 操 作 运 算 代 法，所以索引一般不支持会建立空值索引值的。 Oracle应该会用B树索引吧？？ 替，如status is not null 改为 status >0 或stauts >’’ 我个人的一个意见是： 尽量在设计数据库时，对一些经常需要进行判断 的字段，不允许字段为空，而用一个缺省值代替 空值，如样品中状态字段不允许为空，缺省为 Draft等等。 关于>（大于号）<（小于号）的看法 >（大于号）或<（小于号）操作符一般情况下 是没有办法去用其他的操作符取代和优化的，其 支持索引。但在某些情况下可以对它进行优化， 如Folders表有100万记录，字段OrdCount，其 中 20 万 条 记 录 的 OrdCount 为 1 ， 40 万 记 录 OrdCount为2，29万记录OrdCount为3，1万记 录 OrdCount 为 4 。 在 执 行 OrdCount>2 与 OrdCount=3 的 效 果 就 有 很 大 的 区 别 了 ， 因 为 OrdCount>2时ORACLE会先找出为2的记录索 引再进行比较，而OrdCount=3时ORACLE则直 接找到=3的记录索引。 Like操作符可以应用通配符查询，里面的通配符 组合可能达到几乎是任意的查询，但是如果用得 不好则会产生性能上的问题。
在from后面的表顺序会对SQL性能影响很大，在 没有索引及Oracle没有对表进行统计分析的情况 下ORACLE会按表顺序进行链接，由此因为表 的顺序的不合理，会产生十分耗服务器资源的数 据交叉。所以建议将表记录小的放在前面，大的 放在后面。
辅助工具 SQL/PL Develop，特别是其中的Explain Plan Window可以分析你写的语句，本人 建议将所有编写的SQL放入该功能中进行 分 析 ， 优 化 后 在 写 入 Server Script 和 Datasource中
Like操作符
如FOLDERNO LIKE ‘%09%’ 这种查询不会引用 索 引 ， 导 致 全 表 扫 描 ， 而 FOLDERNO LIKE ‘ T09%’ OR FOLDERNO LIKE ‘N09%’ 则会利用 FOLDERNO的索引进行两个范围的查询，性能 肯定大大提高。 Where条件的顺序 WHERE子句后面的条件顺序对数据量比较大的 查询会产生直接的影响。 Select FOLDERNO,FLDSTS,DEPT from FOLDERS where FLDSTS = ‘ Draft ’ and DEPT=’杭州迪安’ Select FOLDERNO,FLDSTS,DEPT from FOLDERS where DEPT= ’ 杭 州 迪 安 ’ and FLDSTS = ‘Draft’ 假设表FOLDERS的FLDSTS、DEPT字段都没 有建立索引，所以执行的时候都是全表扫描，第 一条SQL的FLDSTS = ‘Draft’条件在记录集内比 率 为 60% ， 而 DEPT= ’ 杭 州 迪 安 ’ 的 比 率 只 为 30%，在进行第一条SQL的时候60%条记录都进 行 FLDSTS 及 DEPT的 比 较 ， 而 在 进 行 第 二 条 SQL的时候20%条记录都进行FLDSTS及DEPT 的比较，以此可以得出第二条SQL的CPU占用 率明显比第一条低。 UNION在进行表链接后会筛选掉重复的记录， 所以在表链接后会对所产生的结果集进行排序运 算，删除重复的记录再返回结果。 实际大部分应用中是不会产生重复的记录，最常 见的是过程表与历史表UNION。如： select FOLDERNO from FOLDERS where FLSTS=’OOS-A’ union select FOLDERNO from where FLDSTS = ‘OOS-A’ FOLDERS_OLD
Fra Baidu bibliotek
SQL编写经验汇总： SQL编写经验汇总： 编写经验汇总
技术方面 SQL语句编写 注意点（指导思想） 注意点（指导思想） 解释 一 定 要 避 免 SQL 语 句 出 现 Select * from XXX 类 型 的 语 Select * from XXX有两个坏处： 句，在SQL的Select语句中明确的写出你需要的字段 1、消耗不必要的数据缓冲 2、如果是数据的一行很大，那一行数据很有可 能分布在很多磁盘分区，不分青红皂白，选出一 行的所有数据，必定会造成磁盘的IO操作，消 耗CPU、内存等资源