为什么会有人写出几百行的SQL语句啊？这些人的心态是怎样的？为了凸显自己的强大吗？ 第1页

SQL语句复杂好与不好不能一概而论，写复杂为了凸显自己强大也不见得，这个还得根据具体应用场景和技术流派分析。

现在的互联网应用很多已经不兴关系数据库那一套了，因为并发量大，操作缓存比较多，如直接读写redis或设置进程内存，SQL最多数据落盘的时候用下。有的应用甚至不用关系数据库而是用mongodb，那么连仅有的SQL都省下了。

现在很多年轻的程序员，开发互联网应用出生，对于关系数据库的使用仅限select、update、insert、delete，但是这并不妨碍他们拿高薪，因为程序本身用不上关系数据库的高级特性，对于公司来说，用不上的技术，员工掌握了意义也不大。

mySql应该算是关系数据库管理系统的下限了，就数据库技术的先进性和性能而言，不知道被oracle和sql server甩几条街，但是在互联网行业，照样很流行，因为互联网企业并不需要很多先进的关系数据库特性。

如果在mysql上运行复杂的sql，如嵌套的很深的子查询或者多表连接查询，性能肯定非常差劲。但是换成sql server和oracle就不一样了，这些商业数据库对复杂sql优化支持的很好，索引利用得当，性能会非常好。

此外，也不是所有的应用系统都是高并发的，有的系统可能只是一些内部系统，如OA，用的人不多，但是业务逻辑非常复杂，一个功能涉及到N个表的数据，这个时候复杂SQL就能显现威力了，一个SQL语句就能完成所有的业务逻辑需求，这对于深入掌握SQL的程序员而言，开发效率非常高，这也是有程序员喜欢用复杂SQL的原因，可能这个SQL执行需要一秒，但是对于一些内部系统而言，无所谓啦。

但是复杂的SQL有一个毛病，有门槛，如果一个不精通SQL的程序员去阅读一个复杂SQL，就跟看天书一样，完全看不懂，然后去谷歌百度一顿搜索，依旧看不懂。这和复杂的程序代码不一样，程序代码即使很复杂，只要花时间啃，总是能看明白的，而且也能改进优化。如让一个初级java程序员改一段复杂的业务逻辑实现代码，照样没问题。

然而，让一个对SQL了解仅限增删查改的程序员，去改一段复杂的SQL，就不行了，因为SQL编程本身就比用编程语言编程复杂，SQL语言中看似关键字不多，但是很多关键字都蕴含很多种变化。

如表连接，分out join 、inner join、cross join、full join，还分left join、right join，而且还可以互相组合，组合代码的结果还不一样，差之毫厘谬以千里。

如子查询，分相关子查询，不相关子查询， 不相关子查询还好理解，相关子查询要是没经过系统学习，肯定理解不了。

另外还有case when，pivot、unpivot 这种很有用，但是又不常用的东西，真的会要了没见过的人的命。

因此对SQL掌握不深的程序员见到这种SQL真的会骂娘，因为把他整不会了，而且通过搜索引擎还解决不了问题，必须经过系统的学习，因为SQL编程知识更像一个体系，而不是片段。

题主说的这个程序员估计是传统编程行业出生，而不是互联网行业出生，否则不是这个思维。当然，如果他是大数据库开发人员，也可能会写出这种SQL。

我以前做传统行业的系统，用的.net + sql server，真的很兴复杂SQL这一套解决问题的，同时还会用存储过程、SQL函数、触发器来解决问题，效率很高，开发也很轻松。

后来跑到互联网行业，想在公司应用这套机制，被所有人都喷了，那自然也就不用了。最近在互联网混的这几年，连普通SQL都不写，数据的存取不是redis就是mongodb，要不就是进程内存，复杂SQL怎么写都快忘记了。

最后推荐一本书，有兴趣可以去看看，《SQL Server 2005技术内幕:T-SQL查询》，豆瓣9.4

理解这本书的内容，对SQL的掌握会有翻天覆地的变化，而且是纯实践的，可以堪称神书。