我是怎么用MySQL的
第零篇簡單介紹了austin項目做什么用的，這兩個月我重點(diǎn)會實(shí)現(xiàn)哪一塊內(nèi)容。
第一篇用Maven+SpringBoot搭好了項目的架子，以及聊了下我對SpringBoot和Maven的看法。
第二篇聊了下很容易被大家忽略的日志（這在項目中是非常重要的）
第三篇推薦了些經(jīng)常用到的工具包（簡化我們的開發(fā)也能提高代碼的可讀性）
第四篇實(shí)現(xiàn)了短信發(fā)送的最基本功能
番外篇 #01保姆級教如何使用austin
這是austin項目系列的第五篇了，要進(jìn)入整體開始完善項目的各種功能的階段啦，就從數(shù)據(jù)庫開始入手吧。
今天想跟大家聊聊數(shù)據(jù)庫層面上的事
（注：今天聊的數(shù)據(jù)庫都特指關(guān)系型數(shù)據(jù)庫）
01、數(shù)據(jù)庫選擇
之前發(fā)了一張我可能要在austin項目上引入哪些技術(shù)棧的圖，好多人問我分布式配置中心為什么不選擇Nacos，而是用Apollo。卻沒人問我為什么數(shù)據(jù)庫選擇MySQL。
說起來MySQL，在網(wǎng)上看到的各類Java教程，幾乎都是使用MySQL作為數(shù)據(jù)庫。日常在群里聊各種數(shù)據(jù)庫上的問題，也差不多都是MySQL，只有個別的可能用PostgreSQL和Oracle或其他
就連我在面試的時候，我也沒被面試官問過：“你的數(shù)據(jù)庫為什么選擇MySQL??？這塊技術(shù)選型是怎么樣的”
看到這里，是不是覺得我有答案了？其實(shí)我也沒有。寫到一半的時候發(fā)現(xiàn)我也說不出啥比較好的理由...既然我不知道，于是我就去看看人家是怎么說的。
https://www.zhihu.com/question/21793412/answer/32127410
總結(jié)原因可能是：
前期MySQL免費(fèi)開源易用，從眾多廠商中硬生生搞出了生態(tài)。有了生態(tài)，很難就被干掉了。（最主要的） 互聯(lián)網(wǎng)用MySQL就是用來存數(shù)據(jù)“低成本快速的數(shù)據(jù)存儲插入方案”，要求也相對沒那么高（這條我后面會詳細(xì)聊聊） 很多時候?qū)δ臣夹g(shù)選型并非是技術(shù)原因
而我，我只會MySQL。我在生產(chǎn)環(huán)境下只用過MySQL，當(dāng)年我還是小白的時候接觸過Oracle，但現(xiàn)在也基本忘得差不多了。
很多時候?qū)δ臣夹g(shù)選型并非是技術(shù)原因（我是懶狗，我承認(rèn)了）。近幾年P(guān)ostgreSQL很火，聽說很多地方都比MySQL要好，感興趣的小伙伴可以把a(bǔ)ustin項目的MySQL替換為PostgreSQL
對數(shù)據(jù)庫選型感興趣的大哥們也可以找點(diǎn)資料繼續(xù)查閱資料，也很歡迎在評論區(qū)輸出下自己的經(jīng)驗，這種話題討論我覺得還是蠻有意思的。
跟著我一起做austin項目的小伙伴應(yīng)該對關(guān)系型數(shù)據(jù)庫都有所了解了，這里的基礎(chǔ)我就不展開講述了。對MySQL感興趣或者準(zhǔn)備要面試的同學(xué)，可以看看我《對線面試官》系列的MySQL章節(jié)（在各大博客平臺中受到了不錯的反饋）
02、ORM框架選擇
記得幾年前我剛接觸數(shù)據(jù)庫和Java的時候，那時候要用JDBC連接數(shù)據(jù)庫來操作數(shù)據(jù)，我就很不解：明明我可以通過各種的數(shù)據(jù)庫客戶端就能對數(shù)據(jù)進(jìn)行操作，為啥我要用JDBC，好麻煩??！
至于為什么會有這種疑問，我也不理解我當(dāng)時是怎么想的（哈哈哈哈）。后來想通了以后，也學(xué)習(xí)了很多在程序上“簡化JDBC模板”的姿勢（DBUtils/Hibernate/Spring JDBC/Mybatis/SpringData JPA)
我在生產(chǎn)環(huán)境中接觸過的都是Mybatis，但這一次我在asutin項目中決定使用SpringData JPA作為ORM框架。
03、使用數(shù)據(jù)庫的經(jīng)驗
這兩年我是呆在互聯(lián)網(wǎng)公司上班的，我就來聊下我個人所接觸到的東西，分享下我的看法。
一般來說，每個業(yè)務(wù)團(tuán)隊維護(hù)著自己的數(shù)據(jù)庫（一個業(yè)務(wù)團(tuán)隊可能就有好幾個庫），當(dāng)我們需要某一個團(tuán)隊的相關(guān)數(shù)據(jù)時，團(tuán)隊會提供對應(yīng)的RPC接口給公司內(nèi)部業(yè)務(wù)使用。
這意味著數(shù)據(jù)邏輯對調(diào)用業(yè)務(wù)方而言，是透明的（調(diào)用業(yè)務(wù)方不需要關(guān)注其他團(tuán)隊數(shù)據(jù)庫的任何信息，無論是數(shù)據(jù)庫表設(shè)計還是具體的字段）。
這個好處是顯然地：要某團(tuán)隊的業(yè)務(wù)數(shù)據(jù)，只要找到他們提供的接口就完事了。作為需求方，只需要調(diào)個接口就能拿到自己想要的數(shù)據(jù)。
回到數(shù)據(jù)庫內(nèi)部存儲本身，我們會盡可能將表結(jié)構(gòu)設(shè)計得更簡單：在很多情況下，都會放棄數(shù)據(jù)庫三大范式來設(shè)計表。
舉個很簡單又可能不太恰當(dāng)?shù)膱鼍埃阂粋€作者可能會寫多篇文章（意味著多篇文章會屬于同一個作者） author:content(1:N)
那在初學(xué)的時候，可能有的教程會這樣設(shè)計：author表、content表、autor_content_mapping表
但是，我們在實(shí)際中生產(chǎn)環(huán)境中很有可能是不設(shè)計這種關(guān)聯(lián)表，而是直接把相關(guān)字段冗余在一張表里。這樣在查詢的時候，就能直接通過一張表查到對應(yīng)的信息了，不用進(jìn)行多層關(guān)聯(lián)
如果按上面的結(jié)構(gòu)進(jìn)行查詢：比如我要查到某一篇文章的作者基本信息，那我此時的動作是：
關(guān)聯(lián) author_content表查到文章的authorId通過 authorId去author表查到作者的基本信息
如果我把authorId直接存到content表中，那就意味著少了去author_content表查詢了。
注：這里我不是說讓你們把所有的信息都存在一張表里，一張表里有上百個字段，千萬不要誤會我的意思！
說起關(guān)聯(lián)，又有一個能聊的話題：是否join（這個話題我曾經(jīng)在我的交流群中聊過，不過也是各抒所見吧）。我在以前公司接觸到的項目，在mapper.xml中都看不到join的身影，我寫join只在hive寫統(tǒng)計腳本的時候用到。
【強(qiáng)制】超過三個表禁止 join。需要 join 的字段，數(shù)據(jù)類型必須絕對一致；多表關(guān)聯(lián)查詢時，保證被關(guān)聯(lián)的字段需要有索引。
說明：即使雙表 join 也要注意表索引、SQL 性能。
喜歡用join的會告訴你：我寫join會讓代碼變得更簡單。查數(shù)據(jù)太麻煩了，要查的數(shù)據(jù)會存到多張表里，直接在用join的開發(fā)效率是最快的！
而我，我是支持在代碼里寫業(yè)務(wù)邏輯的。所有都是單表查詢，在程序代碼中對數(shù)據(jù)進(jìn)行關(guān)聯(lián)（數(shù)據(jù)庫的JOIN能干到的事，在程序上一定能干得到）。這樣的好處就在于：SQL簡單，SQL易復(fù)用，SQL易優(yōu)化
在絕大數(shù)情況下，我們的接口瓶頸都是來源于「數(shù)據(jù)庫」，而非應(yīng)用服務(wù)器。多JOIN且復(fù)雜的SQL是不好優(yōu)化的，而簡單的SQL是比較好優(yōu)化的，并且我認(rèn)為程序邏輯往往都要比SQL更容易維護(hù)。
在我這兩年在互聯(lián)網(wǎng)公司中，關(guān)系型數(shù)據(jù)庫在我的認(rèn)知里，它就是作為一個支持事務(wù)的存儲。如果我們存儲的數(shù)據(jù)對事務(wù)沒有要求的，可能壓根就不需要存儲至關(guān)系型數(shù)據(jù)庫中。
現(xiàn)在數(shù)據(jù)源可選擇的太多了，我們可以把數(shù)據(jù)存儲到Redis(內(nèi)存數(shù)據(jù)庫)、Elasticsearch（搜索引擎）、HBase（分布式、可伸縮的大數(shù)據(jù)存儲）、HDFS（分布式文件系統(tǒng)）、clickhouse（OLAP存儲系統(tǒng)）等等等
基于上面這些背景下，我的查詢SQL就不會復(fù)雜，那么Spring Data JPA不就很適合我了么？
04、開發(fā)之外的數(shù)據(jù)庫
去到有一定規(guī)模的公司，都會有數(shù)據(jù)庫相關(guān)的基礎(chǔ)建設(shè)，下面提下常見的基礎(chǔ)建設(shè)吧
一、DDL和DML都需要走工單
生產(chǎn)環(huán)境的數(shù)據(jù)庫理論都不能通過自己編寫接口在程序中修改（高危動作），需要修數(shù)據(jù)或者建表都需要經(jīng)過工單系統(tǒng)審核（一般是數(shù)據(jù)庫負(fù)責(zé)人+DBA）
比如你提交建表申請，DBA會看你的表設(shè)計是否合理（是否有加索引等等）
二、DQL查詢線上數(shù)據(jù)需要權(quán)限
我們要查詢線上的數(shù)據(jù)，一般都得申請庫的權(quán)限，有了權(quán)限之后在公司內(nèi)網(wǎng)特定的頁面進(jìn)行數(shù)據(jù)查詢（我們一般只需要查團(tuán)隊內(nèi)的數(shù)據(jù)，所以其實(shí)也還好，其他團(tuán)隊的數(shù)據(jù)庫權(quán)限是不開放的，要數(shù)據(jù)一般只能通過接口獲取）
三、程序上一般不直連數(shù)據(jù)庫（會有代理層）
一般只有線下數(shù)據(jù)庫可以通過ip直連，線上數(shù)據(jù)庫都會經(jīng)過代理層（代理層可以做很多東西，包括監(jiān)控鑒權(quán)分庫分表等等）
四、完備的監(jiān)控告警
數(shù)據(jù)庫作為一個很重要的存儲之一（如果掛了是真的影響很大），會有完備的監(jiān)控和告警。比如說執(zhí)行SQL失敗的告警、執(zhí)行慢SQL的告警等等，對數(shù)據(jù)庫的各種指標(biāo)進(jìn)行實(shí)時監(jiān)控
05、austin建表DDL
如果有提前預(yù)習(xí)的同學(xué)，應(yīng)該就知道在austin.sql下我放了兩張表的DDL。為了讓大家理解我在做什么，我來解釋下這兩張表的DDL具體是什么含義（為什么我要建這兩張表）
從message_template這張表開始解釋吧，所有的字段我都添加了注釋，應(yīng)該還是比較容易看得懂的。
注：如果程序由于擴(kuò)展導(dǎo)致數(shù)據(jù)庫注釋有落后，還是有必要更新下（造福后人）
我們需要讓所有的消息都有一個「載體」，這個載體說白了就是模板，模板是austin系統(tǒng)的基石（有了模板，才能做業(yè)務(wù)處理，才能溯源，才能數(shù)據(jù)統(tǒng)計，才能擴(kuò)展出一整套的建設(shè)...）
下面聊下幾個可能大家有疑問的幾個字段吧：
audit_status和flow_id：模板在發(fā)送之前需要經(jīng)過審核（這在發(fā)送消息里非常重要，這會很大程度上能防止對消息的誤發(fā)（相信大家也能看到各大公司都有過發(fā)錯消息的報道）msg_type消息類型：分隔不同的消息類型，可以在下發(fā)時讓不同的類型走不同的通道進(jìn)行實(shí)現(xiàn)消息隔離（營銷類的消息即便堵住了，也不會影響到通知類的消息）send_account發(fā)送賬號：一個渠道內(nèi)可能會有多個賬號發(fā)送（比如，郵件渠道可以選擇不同的郵件組進(jìn)行發(fā)送、短信渠道可以選擇不同的短信類型賬號進(jìn)行發(fā)送）deduplication_time和is_ngiht_shield平臺規(guī)則：作為發(fā)送類型的組件(平臺)，需要有通用的規(guī)則。而去重和夜間屏蔽下發(fā)這種就很適合在平臺內(nèi)做msg_conteng：這個字段是作為消息內(nèi)容發(fā)送的核心，不同的渠道對應(yīng)下發(fā)的格式都不一樣，我后面會直接將JSON存儲進(jìn)去。支持占位符的方式進(jìn)行替換...
有可能后續(xù)還會擴(kuò)展字段（畢竟在初期考慮設(shè)計表的時候，不會盡全盡美）。這種作為模板或者理解為配置的表，從使用上就注定它不會有很大的數(shù)據(jù)量。
下面來看下sms_record表吧，其實(shí)這表能說的不多（就是要把短信發(fā)送的記錄以及短信的回執(zhí)存儲進(jìn)去）。它的作用一方面是能追蹤到為何發(fā)送給某個用戶的短信失敗了，另一方面是將這些記錄進(jìn)行關(guān)聯(lián)做對賬使用。
06、總結(jié)
這篇文章其實(shí)想我聊的是：數(shù)據(jù)庫是一個很重要的角色，如果它掛了會影響很大很大。但同時，我們很多時候都是“輕量級”地去使用它（通過簡單的SQL），它的存在很多時候是因它能很好地支持事務(wù)（數(shù)據(jù)強(qiáng)一致性）。
我們最能夠信任的數(shù)據(jù)就是存儲在數(shù)據(jù)庫的，其他的存儲我們可能擔(dān)心會丟、會多、會不實(shí)時等等（這是數(shù)據(jù)庫比其他存儲的最大的優(yōu)勢）
我說得不對一定，不要以我的為準(zhǔn)，我們可以在評論區(qū)聊
《對線面試官》公眾號還在持續(xù)分享面試題，沒關(guān)注的同學(xué)可以關(guān)注一波！這是austin項目的上一個系列，質(zhì)量桿桿的。持續(xù)的創(chuàng)作離不開你的點(diǎn)贊和轉(zhuǎn)發(fā)分享！