?我們在寫SQL代碼的過程中，總會遇到一些奇奇怪怪的問題，比如少了個分號，標點符號寫成全角了，表名多了個空格等等。這些問題一執行就報錯，錯了怎么也找不出問題所在。

今天給小伙伴講講如何寫出高質量的SQL代碼？

何為高質量？就是這段代碼讀起來一目了然：邏輯清晰，代碼整潔，執行起來還賊快。

明確業務需求

寫SQL代碼首先肯定是要搞清楚為何要這樣寫，=和<>其實有天壤之別，>=和>雖然只多了一個=，可能就是這個等好就排除了不知道多少數據。

這些情況都需要我們搞清楚業務需求才能敲代碼，如果遇到一個模糊的需求，會把你折騰的死去活來（親身體會，含淚警告）。

如果你是剛工作的小白，可千萬別害羞去問別人需求。一旦你害怕去問別人，你的工作任務就會越堆越多，而你整天也會因為沒有需求無所事事或者寫的都是沒意義的代碼。

最后不出三個月，試用期還沒結束，一紙：您的試用期表現不符合我司要求，我們終止與您的勞動合同。那可就悲劇了。

此外，有些需求是需要我們去挖掘的，就是當業務部門提出他的想法的時候，又不是很明確，這個時候需要我們去引導他們該如何做更好。其實這個時候是避免業務給你挖坑的最好時機。

當然，如果是正當需求，且非常明確的，你就只能照做了，不管它是不是坑。

代碼注釋兩不誤

代碼是我們解決需求的唯一武器，而注釋是你了解武器該如何使用的說明書。

一提起注釋，很多人都不屑于去寫。

A：“這代碼邏輯不是很明白嗎？就是將這兩個表進行表關聯，排除這些數據，再排除那些數據，最后顯示這些數據，還要寫注釋干嘛啊？”

B：“說了這么一長段話，你直接注釋一下這個語句是查詢VIP用戶近三個月的流水不就得了？”

注釋往往不是寫給自己看的，更多的是寫給其他需要使用到這段代碼的同事看的。現在的工作都講究協同工作，每個人只是這項工作中的一小部分。

你寫的代碼可能有很多人需要使用，如果每個人在使用之前都要看懂你這個代碼意思，才能繼續寫代碼，那多費時間啊！

所以注釋一定要寫。而且有時候，如果你寫的代碼很長很長，沒有加注釋的話，你回頭重新讀一遍，可能都不知道自己完成了什么功能。

而時間就是金錢，給別人干活，看的就是單位時間的產出，產出低了那到手的金錢（工資）肯定就低了。

代碼格式化

這其實是說的一個代碼是否整齊好看，有些SQL開發平臺對大小寫，分號還是很敏感的，這個時候如果你寫的代碼是一坨，那這個需要調試的概率就很大了。

現在寫代碼的工具都挺智能化的了，之前我在知識星球給星友們推薦了一款非常智能的插件：SQL Prompt。

這款插件不僅可以自動將關鍵字給你大小，還有各種智能提示，比如表名，列名，函數名，視圖，存儲過程幾乎都可以提示，而且還能顯示相關具體代碼，此外還有一鍵排版功能，當然這個很多管理工具都自帶了。

好看的代碼就像看到一道美麗的風景，讓人心曠神怡（有點夸張），有繼續讀下去的意愿。而裹成一坨，大小寫相互交錯，反正我是看著非常頭疼。

優化優化再優化

一切都做好了，就等代碼執行了，然而執行過程一等少則幾分鐘，多著幾個小時，這樣的代碼估計沒人敢用吧。

而SQL非常講究效率，有時0.01秒的等待可能都會造成蝴蝶效應，久而久之，最終導致死鎖或異常。

這個時候就需要我們，對自己寫的SQL代碼好好的優化一番。優化的方法我在之前的推文中提到了很多，而SQL優化的根本就在于執行計劃。

執行計劃是我們了解數據庫執行代碼的唯一窗口，通過執行計劃可以洞悉SQL代碼使用了哪些方法來取數。是直接全表掃描，還是沒有按照我們預想走索引，抑或是關聯的表太多等等，都是我們需要去解決的問題。

通過執行計劃給出合理的優化方法，不管是建索引，還是改代碼，這都是我們向高質量SQL更進一步的有效措施。

當然世上沒有絕對完美的代碼，但是作為一個程序員：

寫出高質量SQL應該是我們的最高宗旨！