作为一个具有十多年一线数据库实战经验的“大佬”，经常有人问我：我想转行IT，该选择哪个方向呢？听说数据分析入门很简单，学学Excel、SQL、Python啥的就搞定了，分分钟年薪百万。

我不是泼冷水啊，在这里，先亮出我的观点：SQL是一门入门容易，进阶很难的语言。

工作这么多年，经过我面试的人，没有上百，也有大几十了。真正有SQL思维，能把SQL语句写的好的人，寥寥无几。

可为啥还说SQL是一门入门很容易的语言呢？

看见上面这个SQL语句了没。这是一句最简单的SQL语句，任何复杂的SQL语句，都是基于它演化而来的。

只要你认识英文字母，认识数字，相信上面这个语句没有看不懂的。

它表示的含义是，查询一个数字1，作为结果返回给SQL的调用者。

基于这个SQL，复杂一些的话，可以增加FROM子句，WHERE子句，GROUP BY子句，或者再跟其他表关联一下等等。SQL马上就变的复杂了。

而且，学习SQL语言，把SELECT语句写好了，基本就学会了90%，因为绝大多数情况下，我们使用SQL都是用来查询数据的，而且其他的语句都超级简单。

我有一个同事，非计算机专业的，非常逗。每次去我的工位上，都要问我在干什么，我说我在写SQL语句，在写SELECT查询。

他说，你每天都是在写SELECT查询？

我说，是的，我每天99%的时间，都在写SELECT查询。

他不信，你们工作就这么简单？

我说，真的这么简单。

最后，他总是要求我把我写的程序打开给他看。然后，我就真的打开我写的存储过程给他看，里面真的99%都是SELECT查询语句。

他这才相信。

你别笑，我们平时工作，使用到的SQL语句，还真是99%都是SELECT语句。

这是SQL语言的核心。

毕竟SQL的全名叫结构化查询语言。数据写到数据库，是为了做什么用的？当然必须肯定是为了查询的啊。

所以说，学好了SELECT，基本就等于学会了SQL。

可是，要做到“学会”，还真不是一件容易的事。

就像我在前面说的，我面试过至少大几十个专业做数据处理的面试者，能把SELECT写好的人，寥寥。

为啥？

首先第一步，写SELECT是为了什么？是为了按查询者的需求查询出数据来。那么，准确的理解需求，本身就是一件很难的事情。

一般来说，查询需求可能是由业务人员提出来的。而业务人员作为非IT人士，可能提出来的需求本身就有一些瑕疵。需要IT人员基于自己的理解，加上对业务知识的掌握，经过与业务人员的多轮讨论，最后才能把需求明确下来。

而且，很多时候，即便是自己提出的查询需求，在转化为SQL语句的过程中，也并不一定能100%转换准确。毕竟，我们这个世界使用的自然语言，与计算机界的SQL语言，还是有一些不同的。

其次，对SQL语法和功能的掌握，并不一定非常到位。

最简单的，有多少人真正的了解NULL值？

LEFT JOIN和INNER JOIN有什么区别？过滤条件放在不同的位置，对查询结果有什么影响？

SELECT子句，能影响查询结果的记录数吗？

这些问题，如果不是经过长期的实战，踩过足够多的坑，是很难有深刻理解的。

当然，还有更高层次的，比如SQL执行的效率是否足够高？实现需求的算法是否简洁等。

比如，如何才能最大化的利用索引来提高查询效率？

SQL这么写，会不会导致索引失效啊？

甚至于，多张表关联，关联顺序应该怎么放呢？关联条件应该怎么写才能利用到特定数据库的特性呢？

不同的数据库，设计思想和应用定位，是不尽相同的。表现在使用上，就是SQL语句不仅要考虑到语法是否正确，还要考虑到是否利用到特定数据库的某些特性。比如Oracle的Hint(提示)、DB2的分区键、MySQL的存储引擎。

另外，别看我们是在写SELECT，其实很多工作，已经做在SQL语句编写之前了。比如，表结构的设计，索引、分区的设置，数据量的预估等等。做不好这些准备工作，想写出一个简洁高效的SQL语句，真是难上加难。

不过，大家也不要灰心，毕竟经验都是积累出来的。一将功成万骨枯，不踩完足够数量的坑、没有一定时长的积累，是很难从入门进阶到专家的。

后面我再写写，如何入门SQL以及如何尽快的进阶。

预告一下，明天的“每周一练”暂停一次，大家开开心心过大年！

推荐阅读：

《SQL中的集合操作，你用过几个？》

《使用SQL进行数据去重的N种方法》

《每周一练：第3周》