格式良好的sql并不会比乱七八糟的sql运行效果更好。数据库其实不怎么关心sql语句中你把逗号放到了字段名的前面还是后面。为了你自己思路清楚，应该做一个有效率的sql编写者，我建议你遵守以下这些格式规则。在本文中我将分享如何通过格式良好的sql语句提升生产率。我定义的效率指的是能从sql 输出准确的结果，并且代码清晰易于理解、修改和调试。我只列出了“SELECT”语句，因为我写的sql语句99%都是查询语句。格式化sql代码是非常个性化的事，我也很清楚因人而异，开发者都认为自己的格式化规则是最合理的。

样例问题

下面是一个典型的sql应用场景，业务报表的数据来自三张表，客户表、销售表和地域表。基于2015年一月份的数据，该报表需要展示在每个行政区内的客户总数和销量总数。该需求通过一个简单的sql语句就可以实现，需要关联查询三张表。

数据可能出现的问题

虽然sql很简单，但保证你的结果正确仍然是真正的关键，因为有下面一些原因可能导致错误：

数据可能来自不同的数据源。也就是说你不能保证这几个表之间的完整性。具体举例来说，你不能假定客户表中所有的邮政编码都是有效的邮政编码，并且一定在地域表中存在。
录入客户表数据的应用可能捕获到未经验证的地点数据，可能会包括错误的邮政编码。
邮政编码表可能不是完整的。新发布的邮政编码可能没有在发布后及时导入到表中。

第一原则

对我来说，相比于编写清晰易读的sql，从sql得到正确的结果才是第一要务。我要做的第一件事就是编写下面的sql语句来获取客户总数。在我写完整个语句之后我会再调整它。

我写的第一个语句是这样的：

这个查询很重要，因为它紧紧围绕第一原则。因为没有sql管理查询，也就没有依赖，我知道这就是客户数量的正确结果。我把这个结果记下来，因为我总需要拿这个数字来衡量后面的sql(是否正确)，在本文后面也会多次提到。

下一步要做的事就是添加必要的字段和表完成查询。我特意把“添加”这个词高亮标注出来，因为根据我的规则，我会在应用第一原则时把能获取相同结果的查询注释掉。下面就是我最终格式化的查询语句。

格式化sql

下面就是根据我的格式化思路推荐的格式化sql。

总是使用表别名

时间会证明这么做是有必要的。如果你没有对sql语句中用到的每个字段使用别名，在将来某个时候可能会给这个查询语句添加进来别的同名字段。到那时候你的查询乃至报表就会产生错误(出现了重名字段名)。

逗号放到字段之前

在调试或者测试我的查询语句时，这么做可以方便地注释掉某个字段，而不需要修改其它行，所有的逗号都没有缺少或多余。不这么做的话你可能总要调整逗号才能保证语句正确。如果你经常要调试语句，这么做会带来极大方便，效率会更高。这个做法对“SELECT”部分和“GROUP BY”子句部分同样适用。

在开发时我使用“SELECT 0”作为语句的开始，迁移到正式环境时它很容易删除掉。这样我们就可以在后面所有字段前面都写都好了。没有这个“0”的话，如果我想注释掉第一个字段(本例中是“c.cust_post_code”)，我就必须处理后面的逗号问题。我必须临时注释掉它，将来还要加回来。在“GROUP BY”语句中也是一样的。这个“0”是额外加的。

把“JOIN”放到独立行

把“JOIN”语句放到独立行有以下

好处

这么做很容易看到本查询语句涉及的所有表，只需要看滚动“JOIN”语句就可以了。

使用“JOIN”相比于在“WHERE”子句中列出所有表和表达式关系，可以把所有逻辑关系都放到一个地方。我们不可能总是吧“JOIN”语句放到一行中，但是至少应该放到一起。

这么做的话要注释掉“JOIN”语句也是相对容易的。这在调试时非常有用，你可能需要知道是否是“JOIN”引起了数据问题。

列模式编辑

在处理大量字段的情况时，列模式编辑非常方便。下面是我曾经做过的第一个动态GIF展示，你可以注释掉所有非聚集字段。我使用了列模式编辑，而不仅仅是注释掉字段：

创建全部索引

在使用字段较多的UNION语句时：

注释掉“GROUP BY”子句的字段清单

测试查询结果

我必须使用外连接“OUTER”列出所有客户，因为不是所有客户的邮政编码都在地域表里有相应的邮政编码。我可以通过包含和排除不同字段和表反复操作来确保我查询的结果与最开始那个查询(单独查询客户的那个语句)结果相同，这其实是对第一原则的遵守。

像这样的sql对我来说意味着我必须写独立的测试来检查数据。通过注释掉的那几行语句我可以使用第一原则验证我查询数据的准确性。这么做提高了我的效率和报表。

以上就是本文的全部内容，希望对大家的学习有所帮助。