写这个话题心里有点没底，主要是我们微信群里懂SQL的大佬越来越多。如果说的不到位，那就糗大了。技术上的东西没有模棱两可，一就是一，二就是二，所以这篇文章权当抛砖引玉，如有不到之处还请轻拍。
我们在写SQL代码的过程中，总会遇到一些奇奇怪怪的问题，比如少了个分号，标点符号写成全角了，表名多了个空格等等。这些问题一执行就报错，错了怎么也找不出问题所在。
今天给小伙伴讲讲如何写出高质量的SQL代码？
何为高质量？就是这段代码读起来一目了然：逻辑清晰，代码整洁，执行起来还贼快。
明确业务需求写SQL代码首先肯定是要搞清楚为何要这样写，=和<>其实有天壤之别，>=和>虽然只多了一个=，可能就是这个等号就排除了不知道多少数据。
这些情况都需要我们搞清楚业务需求才能敲代码，如果遇到一个模糊的需求，会把你折腾的死去活来（亲身体会，含泪警告）。
如果你是刚工作的小白，可千万别害羞去问别人需求。一旦你害怕去问别人，你的工作任务就会越堆越多，而你整天也会因为没有需求无所事事或者写的都是没意义的代码。
最后不出三个月，试用期还没结束，一纸：您的试用期表现不符合我司要求，我们终止与您的劳动合同。那可就悲剧了。
此外，有些需求是需要我们去挖掘的，就是当业务部门提出他的想法的时候，又不是很明确，这个时候需要我们去引导他们该如何做更好。其实这个时候是避免业务给你挖坑的最好时机。
当然，如果是正当需求，且非常明确的，你就只能照做了，不管它是不是坑。
代码注释两不误代码是我们解决需求的唯一武器，而注释是你了解武器该如何使用的说明书。
一提起注释，很多人都不屑于去写。
A：“这代码逻辑不是很明白吗？就是将这两个表进行表关联，排除这些数据，再排除那些数据，最后显示这些数据，还要写注释干嘛啊？”
B：“说了这么一长段话，你直接注释一下这个语句是查询VIP用户近三个月的流水不就得了？”
注释往往不是写给自己看的，更多的是写给其他需要使用到这段代码的同事看的。现在的工作都讲究协同工作，每个人只是这项工作中的一小部分。
你写的代码可能有很多人需要使用，如果每个人在使用之前都要看懂你这个代码意思，才能继续写代码，那多费时间啊！
所以注释一定要写。而且有时候，如果你写的代码很长很长，没有加注释的话，你回头重新读一遍，可能都不知道自己完成了什么功能。
而时间就是金钱，给别人干活，看的就是单位时间的产出，产出低了那到手的金钱（工资）肯定就低了。
这其实是说的一个代码是否整齐好看，有些SQL开发平台对大小写，分号还是很敏感的，这个时候如果你写的代码是一坨，那这个需要调试的概率就很大了。
现在写代码的工具都挺智能化的了，之前我在知识星球给星友们推荐了一款非常智能的插件：SQL Prompt。
这款插件不仅可以自动将关键字给你大写，还有各种智能提示，比如表名，列名，函数名，视图，存储过程几乎都可以提示，而且还能显示相关具体代码，此外还有一键排版功能，当然这个很多管理工具都自带了。
好看的代码就像看到一道美丽的风景，让人心旷神怡（有点夸张），有继续读下去的意愿。而裹成一坨，大小写相互交错，反正我是看着非常头疼。
一切都做好了，就等代码执行了，然而执行过程一等少则几分钟，多着几个小时，这样的代码估计没人敢用吧。
而SQL非常讲究效率，有时0.01秒的等待可能都会造成蝴蝶效应，久而久之，最终导致死锁或异常。
这个时候就需要我们，对自己写的SQL代码好好的优化一番。优化的方法我在之前的推文中提到了很多，而SQL优化的根本就在于执行计划。
执行计划是我们了解数据库执行代码的唯一窗口，通过执行计划可以洞悉SQL代码使用了哪些方法来取数。是直接全表扫描，还是没有按照我们预想走索引，抑或是关联的表太多等等，都是我们需要去解决的问题。
通过执行计划给出合理的优化方法，不管是建索引，还是改代码，这都是我们向高质量SQL更进一步的有效措施。
当然世上没有绝对完美的代码，但是作为一个程序员：
写出高质量SQL应该是我们的最高宗旨！
