关于SQL优化的一点感想

        项目进展到后期，需要在页面进行一个4表关联查询，数据并不复杂，但是需要将部分数据进行转化（根据元数据表的id转化为具体内容，例如将value=1的地区转发为“北京”）。

        4个表中有两个表的属性较多，大概30+20，其他两表属性都较少。4个表中有两个表的数据量较大，大概10w+5w条，其他两表数据量在1w以内。优化顺序如下：
        1）最开始，我只用最基本的查询，依次left join各个表。但是这样的sql在oracle中执行大概是50s左右，基本不可忍受；进行优化，将里面的一个数据转化，从sql抽出function，基于一般认知，function是经过oracle优化的，应该比正常sql快；优化后，执行话费时间为40s左右，基本上没有本质区别；但是，如果不进行这个数据的转化可以缩小到5s左右的时间；这个属性的转化需要将一个字符串id转化为名字字符串，例如： 100/101/102-> 李明/王明/小明。从中可以看出，这个sql话费的时间很多，而且就算用function也需要很长时间。
        2）再次进行优化，将这个数据的转化移到系统中间层，在程序中去做，也即，查询出来的数据List进行扫描，然后利用调用此前编写好的function，返回字符串，赋值到List相应的地方。执行话费时间缩小到不可思议的6s，基本上和不进行转化的数量级一致；基于一般理解，在sql中处理数据会比在程序中快，但有时候往往不是这样。因为此前的sql需要调用大量的链接，本身转化有相对独立，移入程序后，在内存中进行数据获取并不慢。关键一点，查询显示结果是分页的，我们并不需要一次性进行上万条的数据转化，每次只需要进行几十条而已，数据大大提高；
        3）最后，必然是进行索引的建立，根据链接的id建立索引，话费时间缩短到500ms。      

        总结，sql优化没有一成不变的方法，需要根据具体的sql语句来优化，而且往往想当然的事情在真实环境中并不一定成立，比如在本例中将属性转化移入程序反而比在sql中做要快。