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