使用SQL不当将会严重影响Sybase IQ性能
项目中使用SQL不当导致Sybase IQ严重性能问题的真实案例:
需求如下：
有一个A表，它的记录数约在50万左右，一个B表，它的记录数在800万左右，B表需要以每月约50条的记录数增长。而A表和B表的唯一索引都是key1和key2，这两个字段大家也可以看作两表的主键。
目前的要求是：
1、需要将B表中与A表中有相同主键的记录的其它字段更新为A表中的字段值。
2、需要将A表中不在B表中的记录插入B表中。
我的同事根据上面这两个要求写出的SQL：
#1: update B
set a.col1=b.col1,
a.col2=b.col2,
.......
from A
where A.key1=B.key1
and A.key2=B.key2
#2 insert B
select key1,key2,col1,col2.....
from A
where not exist(select 1 from B where key1=A.key1)
出错现象：
在将以上两步的SQL语句放入一个存储过程中去运行后，出现的结果让人使料不及，连续运行了11个小时竟然没有出来结果，并且把8个CPU和24G内存的一台小型机资源耗尽，连telnet都连接不上。后来，在仔细检查了该存储过程后，发现第二步中漏掉了一个关联字段，我们将第二步改成：
#2 insert B
select key1,key2,col1,col2.....
from A
where not exist
(select 1 from B where key1=A.key1 and key2=A.key2)
在执行此SQL语句后，依然许久都没有出现结果。 通过分析运行该存储过程时Sybase IQ的日志记录，发现问题的关键出在第2步上。一执行到这里就卡壳。于是，把重点放在对该语句的优化上。看起来用not exists对大表操作时会导致严重的性能问题。所以，我们就将第2步分成以下几个步骤：
#3 select * into #tmp from A
# 4 delete #tmp
from B
where #tmp.key1=A.key1 and #tmp.key2=A.key2
#5 insert into B select * from #tmp
再次执行改存储过程后，通过观察Sybase IQ的运行日志，发现执行完3-5步耗时在100秒左右。整个存储过程的执行时间不超过2分钟。
总结：
1、小心“灯下黑”，千万不要忽略简单的问题；
2、在日常的数据库管理中，为了实现同样的目标，不同的的SQL写法性能相差可能上万倍，而这些性能的差异都是可以通过变换思路的方法得以解决；
3、虽然Sybase IQ是目前最快，性能最优良的数据库引擎，但我们也不应忽视SQL的性能问题；
4、在Sybase IQ中，尽可能用临时表，并且最好使用update和delete操作，尽可能避免使用not exists操作（对于小表，假如数据在1万行左右，可以忽略不计）, 因为not exists可能会导致对大表操作的性能问题。
