程序员老鸟写sql语句的经验之谈

做管理系统的，无论是bs结构的还是cs结构的，都不可避免的涉及到数据库表结构的设计，sql语句的编写等。因此在开发系统的时候，表结构设计是否合理，sql语句是否标准，写出的sql性能是否优化往往会成为公司衡量程序员技术水平的标准。

 

我们程序员不是dba，不需要时刻关注sql运行时间，想方设法优化表结构，存储空间，优化表读取速度等等，但是在开发系统时，时刻保持优良的写sql语句的作风是很有必要的，这关乎到个人在公司的声誉，嘿嘿，你懂的。。。

 

新来的程序员老鸟，在一个开发团队中，需要表现一下自己的水平，奠定在公司的地位，需要努力表现一把，最简单的从写的sql语句就很容易表现出来，曾经就有一次，一个老程序员，上面定位是要做团队领导的，先历练一下做个制单的模块，列表sql中有一列这位老鸟直接写了个select语句从别的表中取之，而不是用表之间关联得到，一下破坏自己程序员老鸟光辉形象。

 

做技术的还是要注重自己的内涵，提升内功，哈哈。

 

闲话少说，总结一点程序员老鸟写sql顺手拈来的功夫吧：

 

1. 不论一个sql中涉及到多个表，每次都用两个表（结果集）操作，得到新的结果后，再和下一个表（结果集）操作。

 

2. 避免在select f1,(select f2 from tableB ).... from tableA 这样得到字段列。直接用tableA和tableB关联得到A.f1,B.f2就可以了。

 

3.避免隐含的类型转换
 如
 select id from employee where emp_id='8'  （错）
 select id from employee where emp_id=8    （对）
 emp_id是整数型，用'8'会默认启动类型转换，增加查询的开销。
 
4. 尽量减少使用正则表达式，尽量不使用通配符。

 

5. 使用关键字代替函数
   如：
   select id from employee where UPPER(dept) like 'TECH_DB'  （错）
   select id from employee where SUBSTR(dept,1,4)='TECH'    （错）
   select id from employee where dept like 'TECH%'         （对）
 
6.不要在字段上用转换函数，尽量在常量上用
  如：
  select id from employee where to_char(create_date,'yyyy-mm-dd')='2012-10-31'  （错）
  select id from employee where create_date=to_date('2012-10-31','yyyy-mm-dd')   （对）
 
7.不使用联接做查询
 如：select id from employee where first_name || last_name like 'Jo%'  （错）
 
8. 尽量避免前后都用通配符
  如：
  select id from employee where dept like '%TECH%' (错）
  select id from employee where dept like 'TECH%' （对）

 

9. 判断条件顺序
  如：
  select id from employee where creat_date-30>to_date('2012-10-31','yyyy-mm-dd')   （错）
    select id from employee where creat_date >to_date('2012-10-31','yyyy-mm-dd')+30   （对）
   
10. 尽量使用exists而非in
 当然这个也要根据记录的情况来定用exists还是用in, 通常的情况是用exists
 select id from employee where salary in (select salary from emp_level where....)   （错）   
 select id from employee where salary exists(select 'X' from emp_level where ....)   （对）
 
11. 使用not exists 而非not in
    和上面的类似
   
12. 减少查询表的记录数范围

 

13.正确使用索引
  索引可以提高速度，一般来说，选择度越高，索引的效率越高。

14. 索引类型
  唯一索引，对于查询用到的字段，尽可能使用唯一索引。
  还有一些其他类型，如位图索引，在性别字段，只有男女的字段上用。

 

15. 在经常进行连接，但是没有指定为外键的列上建立索引

 

16. 在频繁进行排序会分组的列上建立索引，如经常做group by 或 order by 操作的字段。

 

17. 在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不建立索引。如性别列上只有男，女两个不同的值，就没必要建立索引（或建立位图索引）。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。

 

18. 在值比较少的字段做order by时，翻页会出现记录紊乱问题，要带上id字段一起做order by.

 

19. 不要使用空字符串进行查询
    如：
    select id from employee where emp_name like '%%' （错）
   
20. 尽量对经常用作group by的关键字段做索引。

 

21. 正确使用表关联
    利用外连接替换效率十分低下的not in运算，大大提高运行速度。
    如：
    select a.id from employee a where a.emp_no not in (select emp_no from employee1 where job ='SALE')  （错）
   
22. 使用临时表   
   在必要的情况下，为减少读取次数，可以使用经过索引的临时表加快速度。
   如：
   select e.id from employee e ,dept d where e.dept_id=d.id and e.empno>1000 order by e.id   （错）
  
   select id,empno from employee into temp_empl where empno>1000 order by id
   select m.id from temp_emp1 m,dept d where m.empno=d.id      （对）
  
   
 
   
 对于大数据量sql语句性能优化更多的工作就交给dba去实践，我们程序员做好这些基本功就好了。

评论

33 楼 w156445045 2012-10-13  

我用HQL 语句，~

32 楼 liguocai2009 2012-10-12  

我怎么感觉楼主在忽悠我？罗列了一条又一条，但是一个理由没有说？具体例子也没有？

31 楼 cherrycmd 2012-10-12  

第一条虽然很难维护，但是执行效率还是可以的，可以用explain分析看看！

30 楼 dacoolbaby 2012-10-12  

vision2000 写道

eworkflow 写道

魔力猫咪 写道

2并非不可以，只要结果集非常小，可以直接索引定位那么就没问题。
4按需求来。不是你想不用就不用的
6用函数有时没辙，这种情况下可以考虑函数索引
8同4
9标题错误，和判断顺序无关
10好好学习一下吧，不要传播错误观念了。
11同10
12写成驱动表比较好。
14请去学习索引
15干嘛你不指定外键。这里设计有问题。
22直接物化视图不好吗？临时表完了可就没了，每次这么大量写表数据就少了？

多谢这位兄弟指出，匆忙写了一下，在sql执行性能方面，没有绝对的优，都要根据当时的情况来选，换成dba的说法，就是看执行计划，调到最优的效果，也许记录变了，环境变了，过一阵又需要再调整。

我也正准备提这些问题的，有些为什么要这样用，要把情况描述一下，比如 in和exists在oracle里面真正的差距在哪？ 嵌套查询和关联查询适合在什么情况下使用，他们有什么查询优势，索引提高了查询效率但为什么降低了数据的修改效率等等

一句话把结论下了，容易误导新手，不过总结的还不错！

如果你要使用IN，尽量保持IN的数量在20个以内。
超过20个的，直接使用exsits。
效率差很远很远的！！
我的博客里面有解释。

关于索引有必要抽出来讲一下。加多了，占用空间大，加小了，查询效率低。
还有一点，尽量让每一个表都有主键。
如果使用视图，那么不要用太复杂的SQL，因为还不如使用物化视图。
没有什么意思。
适当的复杂查询可以使用WITH语句。
适当使用hint

29 楼 blackproof 2012-10-12  

能够真正发挥一个特定数据库的优势，那才是老鸟
写几句sql，就会遭到鄙视，那工作环境也太恶劣了

28 楼 cqh520llr 2012-10-12  

回复一下

27 楼 vision2000 2012-10-12  

eworkflow 写道

魔力猫咪 写道

2并非不可以，只要结果集非常小，可以直接索引定位那么就没问题。
4按需求来。不是你想不用就不用的
6用函数有时没辙，这种情况下可以考虑函数索引
8同4
9标题错误，和判断顺序无关
10好好学习一下吧，不要传播错误观念了。
11同10
12写成驱动表比较好。
14请去学习索引
15干嘛你不指定外键。这里设计有问题。
22直接物化视图不好吗？临时表完了可就没了，每次这么大量写表数据就少了？

多谢这位兄弟指出，匆忙写了一下，在sql执行性能方面，没有绝对的优，都要根据当时的情况来选，换成dba的说法，就是看执行计划，调到最优的效果，也许记录变了，环境变了，过一阵又需要再调整。

我也正准备提这些问题的，有些为什么要这样用，要把情况描述一下，比如 in和exists在oracle里面真正的差距在哪？ 嵌套查询和关联查询适合在什么情况下使用，他们有什么查询优势，索引提高了查询效率但为什么降低了数据的修改效率等等

一句话把结论下了，容易误导新手，不过总结的还不错！

26 楼 zyn010101 2012-10-12  

Navee 写道

引用

8. 尽量避免前后都用通配符
  如：
  select id from employee where dept like '%TECH%' (错）
  select id from employee where dept like 'TECH%' （对）

小弟不才，求讲解·

下面的可以使用索引，上面的不会使用索引

25 楼 eworkflow 2012-10-12  

wltjack 写道

其实，sql的好坏往往在数据库表的数据量很大的时候才体现的出来。
但是，lz说的很不错，谢谢。

确实是这样，谢谢鼓励，大家共同学习 /wx

24 楼 wltjack 2012-10-12  

其实，sql的好坏往往在数据库表的数据量很大的时候才体现的出来。
但是，lz说的很不错，谢谢。

23 楼 eworkflow 2012-10-12  

raveh 写道

workflow 写道

魔力猫咪 写道

2并非不可以，只要结果集非常小，可以直接索引定位那么就没问题。
4按需求来。不是你想不用就不用的
6用函数有时没辙，这种情况下可以考虑函数索引
8同4
9标题错误，和判断顺序无关
10好好学习一下吧，不要传播错误观念了。
11同10
12写成驱动表比较好。
14请去学习索引
15干嘛你不指定外键。这里设计有问题。
22直接物化视图不好吗？临时表完了可就没了，每次这么大量写表数据就少了？

赞成

+1
同时觉得楼主不应该用“对”“错”来判定。

呵呵，最好用推荐，不推荐 来表示。对错确实不好

22 楼 eworkflow 2012-10-12  

loveuserzzz 写道

楼主，解释一下这个是什么原理：
select id from employee where dept like '%TECH%' (错）
  select id from employee where dept like 'TECH%' （对）

前后都带%%，不会用上dept上的索引

21 楼 eworkflow 2012-10-12  

fatzhen 写道

不说为什么，新手学到的很少，或者被误导
知道了为什么，其实很多都是一回事
建议新手还是学习索引和执行计划吧

我们主要是指在程序开发的时候，写sql时，多想想这些基本的规则。sql的优化方面是没有绝对的优的，需要根据执行计划来相对调优.

20 楼 eworkflow 2012-10-12  

elgs 写道

魔力猫咪 写道

10好好学习一下吧，不要传播错误观念了。
11同10

10和11有什么不对？我的理解也是尽可能用exists而不要用in。

用exists还是用in 这条确实是没有绝对的优，要看记录的范围

    当外面的记录集大，里面的做条件的记录集小，用exists效率高。
    当外面的记录集小，里面的记录集小，用in效率高。
   
昨天我写的时候只是说了一下，要看记录集了，没有详细指出。

19 楼 fatzhen 2012-10-12  

不说为什么，新手学到的很少，或者被误导
知道了为什么，其实很多都是一回事
建议新手还是学习索引和执行计划吧

18 楼 loveuserzzz 2012-10-12  

楼主，解释一下这个是什么原理：
select id from employee where dept like '%TECH%' (错）
  select id from employee where dept like 'TECH%' （对）

17 楼 elgs 2012-10-12  

魔力猫咪 写道

10好好学习一下吧，不要传播错误观念了。
11同10

10和11有什么不对？我的理解也是尽可能用exists而不要用in。

16 楼 elgs 2012-10-12  

10好好学习一下吧，不要传播错误观念了。
11同10


10和11有什么不对？我的理解也是尽可能用exists而不要用in。

15 楼 raveh 2012-10-12  

workflow 写道

魔力猫咪 写道

2并非不可以，只要结果集非常小，可以直接索引定位那么就没问题。
4按需求来。不是你想不用就不用的
6用函数有时没辙，这种情况下可以考虑函数索引
8同4
9标题错误，和判断顺序无关
10好好学习一下吧，不要传播错误观念了。
11同10
12写成驱动表比较好。
14请去学习索引
15干嘛你不指定外键。这里设计有问题。
22直接物化视图不好吗？临时表完了可就没了，每次这么大量写表数据就少了？

赞成

+1
同时觉得楼主不应该用“对”“错”来判定。

14 楼 workflow 2012-10-12  

魔力猫咪 写道

2并非不可以，只要结果集非常小，可以直接索引定位那么就没问题。
4按需求来。不是你想不用就不用的
6用函数有时没辙，这种情况下可以考虑函数索引
8同4
9标题错误，和判断顺序无关
10好好学习一下吧，不要传播错误观念了。
11同10
12写成驱动表比较好。
14请去学习索引
15干嘛你不指定外键。这里设计有问题。
22直接物化视图不好吗？临时表完了可就没了，每次这么大量写表数据就少了？

赞成