使SQL更易于閱讀的幾個小技巧

點擊上方“數(shù)據(jù)管道”，選擇“置頂星標(biāo)”公眾號

干貨福利，第一時間送達

無論是數(shù)倉開發(fā)還是數(shù)據(jù)分析，寫一手好的SQL是一項基本的技能。毋庸置疑，編寫性能較好的SQL是非常重要的，但是，SQL的可讀性同樣是不容小覷的。一個有著混亂格式的SQL腳本，往往需要花費較長的時間去弄清楚腳本的具體邏輯。如果你曾經(jīng)被祖?zhèn)鞯暮翢o章法的SQL腳本狂虐過，你一定心有感觸。本文將分享幾個SQL格式的規(guī)范，當(dāng)然仁者見仁智者見智，其實沒有嚴(yán)格的標(biāo)準(zhǔn)，如果有，那就是保證易于閱讀和易于維護。

秦人不暇自哀，而后人哀之；后人哀之而不鑒之，亦使后人而復(fù)哀后人也

大小寫保持一致

可以對SQL關(guān)鍵字使用不同的大小寫，但是要保持一致。看看這個：

SELECT?customer_city,count(*)?from?dim_customer?WHERE?customerProvince?=?'上海'?Group?by?customer_city

上面的SQL語句是不是很讓人抓狂，大小寫混用，看起來很不規(guī)范。總結(jié)起來，要注意下面幾點：

• SQL的關(guān)鍵字可以大寫，也可以小寫，但是不要大小寫混用。上面的SQL查詢既有完全大寫，也有首字母大寫，更有小寫。看似是不拘小節(jié)，但是萬萬使不得。
• 由于大小寫是混合的，因此很難區(qū)分小寫的關(guān)鍵字實際上是關(guān)鍵字還是列。此外，閱讀也很煩人。
• 字段命名要保持一致的風(fēng)格，上面的SQL與中customer_city是小寫加下劃線，而customerProvince字段是駝峰命名法，這種不一致性顯然是不可取的。

進行一些規(guī)范之后，查詢應(yīng)如下所示：

SELECT?customer_city,
???????count(*)
FROM?dim_customer
WHERE?customer_province?=?'上海'
GROUP?BY?customer_city

使用縮進

再來看看下面的一條查詢語句：

SELECT?dp.region_name,count(*)?FROM?user_behavior_log?ubl?JOIN?dim_province?dp?ON?ubl.province?=?dp.province_name?WHERE?ubl.province?=?'上海市'?GROUP?BY?dp.region_name

將上面的SQL語句格式化下面的形式：

SELECT?dp.region_name,?count(*)
FROM?user_behavior_log?ubl
JOIN?dim_province?dp?ON?ubl.province?=?dp.province_name
WHERE?ubl.province?=?'上海市'
GROUP?BY?dp.region_name

上面的格式化形式似乎清晰了很多，但是如果語句中包含了子查詢、多個JOIN以及窗口函數(shù)時，同樣會顯得對閱讀不是很友好。

再換一種格式化方式，如下：

SELECT
????dp.region_name,?
????count(*)
FROM?user_behavior_log?ubl
????JOIN?dim_province?dp?ON?ubl.province?=?dp.province_name
WHERE?ubl.province?=?'上海市'
GROUP?BY
????dp.region_name

--?或者下面的形式
SELECT
????dp.region_name?
????,count(*)
FROM?user_behavior_log?ubl
????JOIN?dim_province?dp?ON?ubl.province?=?dp.province_name
WHERE?ubl.province?=?'上海市'
GROUP?BY
????dp.region_name

尖叫提示：對于第二種形式，在SELECT字段中，從第二個字段開始，每個字段前面添加一個逗號，而不是每個字段后面使用逗號結(jié)尾。這種方式可以很方便地識別FROM前面是否存在逗號，從而造成語法錯誤。當(dāng)然，這個只是個人習(xí)慣問題，并不是硬性的規(guī)定。

另外上面的SQL語句使用了4個字符縮進，當(dāng)然也可以選擇2個字符縮進，這個也是個人習(xí)慣問題。

在group by 和order by之后使用字段的排列序號

同樣，這種書寫風(fēng)格也是個人的一種偏好，并不是一條硬性規(guī)定。應(yīng)該有很多的初學(xué)者對此種寫法并不是很清楚。

看下面的這條SQL：

SELECT
????dp.region_name,?
????dp.province_name,
????count(*)
FROM?user_behavior_log?ubl
????JOIN?dim_province?dp?ON?ubl.province?=?dp.province_name
GROUP?BY
????dp.region_name,
????dp.province_name
ORDER?BY
????count(*)?desc?--?Hive不支持

可以寫成下面的形式：

--?注意：MySQL、Impala支持這種寫法，Hive不支持
SELECT
????dp.region_name,?
????dp.province_name,
????count(*)
FROM?user_behavior_log?ubl
????JOIN?dim_province?dp?ON?ubl.province?=?dp.province_name
GROUP?BY?1,2
ORDER?BY?3?

這樣寫有如下的好處：

• 可以節(jié)省行：通過許多字段進行分組不僅會在SELECT子句中添加更多行，還會在GROUP BY和ORDER BY子句中添加更多行，甚至可能使查詢中的行數(shù)增加一倍。
• 可維護性：如果想改變分組字段，只需在SELECT子句中進行操作，在GROUP BY語句中不需要修改。
• 方便：只需要GROUP BY 1，2，3，…，n，其中n為分組列的字段序號。

使用Common Table表達式(with語句)

該方式稱之為Common Table Expressions(CTE),用來簡化復(fù)雜查詢。它們可以定義為臨時視圖，因為它們僅在整個查詢執(zhí)行期間存在。

看一個簡單的例子：

--?注意Hive、Impala支持這種語法，低版本的MySQL不支持(高版本支持)
WITH?employee_by_title_count?AS?(
????SELECT
????????t.name?as?job_title
????????,?COUNT(e.id)?as?amount_of_employees
????FROM?employees?e
????????JOIN?job_titles?t?on?e.job_title_id?=?t.id
????GROUP?BY?1
),
salaries_by_title?AS?(
?????SELECT
?????????name?as?job_title
?????????,?salary
?????FROM?job_titles
)
SELECT?*
FROM?employee_by_title_count?e
????JOIN?salaries_by_title?s?ON?s.job_title?=?e.job_title

上面的語句中，最終的查詢使用employee_by_title和salaries_by_title的兩個結(jié)果集進行JOIN產(chǎn)生最終結(jié)果。這比在SELECT子句中或直接在FROM子句中進行子查詢更具可讀性和可維護性。

使用具有描述性的別名

這一點非常重要，如果查詢的列字段很多，肯能會存在一些id，count(*)等，很難辨識代表什么含義，所以需要為每個查詢列加上可讀的、易于理解的別名，能夠讓其他人一眼就能看出代表什么含義，這樣可以增加腳本的可維護性。

總結(jié)

文中提到的一些規(guī)范有些是必須要遵守的，有些是個人的編碼習(xí)慣，無論你是開發(fā)人員、數(shù)據(jù)分析師、數(shù)倉開發(fā)，遵循一些規(guī)范可以避免不必要的麻煩。值得注意的是，關(guān)于SQL的格式，沒有一個標(biāo)準(zhǔn)的約定，需要與團隊的其他成員達成共識，一起按照相同的約定進行開發(fā)，從而可以大大提高腳本的可讀性和可維護性。