1.典型的SQL语句如下
select decode(a,1,’yyy’,2,’xxx’) from t;
转换过程化后的语句是
IF a=1 THEN
‘yyy’
ELSIF a=2 THEN
‘xxx’
end if;
DECODE可以用CASE语句来代替
第一种：
case i when 5 then five
when 6 then six
else I just don’t know
end
第二种：
case when i=5 then five
when i=6 then six
else I just don’t know
end
2.NVL，NVL2函数
通常NULL的操作，合法的表达式有两个
NVL2函数也是判断空的函数，但是有3个参数
NVL(A,B)
NVL1(A,B,C)
NVL1(A,B,C)A,B,C任何一个都会强行调用，而不管B是输出，还是C是输出，B和C都会调用，这是NVL机制决定的，A,B,C三个都会被调用，没有一个表达式可以逃脱，够糟糕吧，在我看来，算是BUG，
这样的设计会引起性能问题，
NVL函数其实很常用的，
但是很多程序员没有注意到它潜在的风险，
3.NVL也可以转换成DECODE语句
那DECODE的机制是不是跟NVL不同呢，
是不是可以避免NVL的隐患呢，答案是：可以，我们可以使用DECODE函数既能完成这业务功能，又能不产生性能问题。
4.本实验是提醒各位，Nvl函数一些内部的机制，避免一些问题发生，
都是一些细节的东西，如果不注意，差别是巨大的，
代价也是巨大的，所以说细节决定命运。
我问大家,DECODE后面的表达式,先后顺序会影响性能吗?
既然DECODE可以解决某些函数性能问题，那DECODE自身是不是有些优化技巧呢，
答案是：DECODE后面的表达式,先后顺序会影响性能
发表评论