寫這個話題心裡有點沒底，主要是我們微信群裡懂SQL的大佬越來越多。如果說的不到位，那就糗大了。技術上的東西沒有模棱兩可，一就是一，二就是二，所以這篇文章權當抛磚引玉，如有不到之處還請輕拍。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!