作为一个具有十多年一线数据库实战经验的“大佬”，经常有人问我：我想转行IT，该选择哪个方向呢？听说数据分析入门很简单，学学Excel、SQL、Python啥的就搞定了，分分钟年薪百万。
我不是泼冷水啊，在这里，先亮出我的观点：SQL是一门入门容易，进阶很难的语言。
工作这么多年，经过我面试的人，没有上百，也有大几十了。真正有SQL思维，能把SQL语句写的好的人，寥寥无几。
可为啥还说SQL是一门入门很容易的语言呢？
select 1;
看见上面这个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以及如何尽快的进阶。
预告一下，明天的“每周一练”暂停一次，大家开开心心过大年！
推荐阅读：
《每周一练：第3周》
