记录详细的需求文档

在写SQL之前必须弄清楚需求, 具体要取什么数据, 有些什么具体的约束条件, 在数据仓库环境中还可以考虑补上这个需求具体对应哪些报表, 对应的基础表如何. 到开发环境的话, 可以考虑加上这条SQL服务于哪些业务(页面),调用频率如何.

不要重新制造轮子

对于一些已经比较成熟的解决方案,有比较现成的例子的SQL,要善于利用已有SQL,已有模板.

降低语句的复杂度

有些同学可能比较喜欢使用比较炫的技术,比较炫的SQL来解决问题. 但是要切记一点, 使用过于复杂过于新的技术, 如果不能在性能(以及其他方面)带来好处的话, 只会使得这条SQL难于维护, 使得其他相关人员难于理解.

小心处理NULL

NULL在Oracle数据库中是一个非常特别的值, 它不等于任何值, 所以如果你的SQL返回的值数量偏少,或者根本不对很可能就是使用NULL出现了问题..常见的情况是:

1. 查询的时候直接使用条件 colx = xxx,而这个colx里面是有NULL值的, 这种情况下查询的返回结果是不会包含NULL值对应的记录的, 如果要查询出NULL对应的记录, 需要使用 colx is null (is not null).

2. var 为null的时候, 在plsql中给var赋值, var := var + xxx;这种情况下var的值会一直是null的, 这一点需要特别注意, 我自己也犯过好几次这个错误.

自己核对数据类型

在where条件里面要仔细地核对数据类型, 由于隐形转换的问题, 在数据类型错误的时候, Oracle无法正确使用索引, 可能会导致SQL运行非常慢.

小心处理重复数据

在需求明确的情况下, 如果你不在乎是否出现重复记录, 或者明确知道不会出现重复数据的情况下, 尽量使用Union All而不是Union进行查询, Union会涉及到昂贵的排序操作.

避免不必要的优化操作

SQL的性能调优可能非常有趣非常带劲, 但是很多时候调优可能意义不大, 比如对于只会使用一次的查询, 你可能很少在乎是1秒钟结束还是2秒钟结束..

不过一些基本的优化规则还是要用的:

只查询你需要的字段, 而不要所有的查询都是用select *来进行.

在通过索引来查询更合适的时候, 尽量在查询条件中指定有索引的字段来查询. (在返回的记录条数很少的时候, 使用索引一般都能更加快速的得到查询结果.不要可以避免使用表连接. 关系数据库就是为了表连接而设计的.

尽可能使用绑定变量

在开发环境使用的SQL语句尽量使用绑定变量, 这样可以大大缓解Oracle数据库解析SQL的消耗, 也可以大大提高数据库的可扩展性.

使用源码控制工具

最好使用CVS/SVN一类的源码控制工具来管理你的SQL/PLSQL代码, 这对于后期的维护有非常大的帮助, 也有助于其他人更好的理解你最初写这条SQL的意图.

测试,测试,测试.

在SQL写好之后, 要深入的进行测试, 以确保其正常运行