前言
可能說起mysql，哪怕一個剛入門的小白都會跟我說，太低級了，這玩意有什麼可整的，沒啥意思，除了增刪改查，索引，序列，還有什麼呢？真當哥們是二B了呀
我就哈哈一笑，小夥子，還是太年輕啊，來看這張圖（平臺原因，像素不夠，需要高清圖，私信“架構圖”獲取）
怎麼樣，兄弟，密集恐懼症是不是犯了啊，還敢說mysql簡單嘛？但是這樣說的話是不是跟我的題目有點不一樣啊，彆着急，接着往下看
增刪改查什麼的都不說，咱就以mysql的優化爲例，來證明一下，爲什麼我說真的不難
既然要說MySQL優化，那我們起碼要先知道現在的MySQL已經爲了讓操作更容易，給我們提供了那些方便吧
MySQL24種系統特性
1．使用 C和C++編寫，並使用了多種編譯器進行測試，保證了源代碼的可移植性。
2．支持AIX、FreeBSD、HP-UX、Linux、Mac OS、NovellNetware、OpenBSD、OS/2 Wrap、Solaris、Windows等多種操作系統。
3．爲多種編程語言提供了API。這些編程語言包括C、C++、Python、Java、Perl、PHP、Eiffel、Ruby,.NET和 Tcl 等。
4．支持多線程，充分利用 CPU 資源。
5．優化的SQL查詢算法，有效地提高查詢速度。
6．既能夠作爲一個單獨的應用程序應用在客戶端服務器網絡環境中，也能夠作爲一個庫而嵌入到其他的軟件中。
7．提供多語言支持，常見的編碼如中文的GB 2312、BIG5，日文的Shift_JIS等都可以用作數據表名和數據列名。
8．提供TCP/IP、ODBC 和JDBC等多種數據庫連接途徑。
9．提供用於管理、檢查、優化數據庫操作的管理工具。
10．支持大型的數據庫。可以處理擁有上千萬條記錄的大型數據庫。
11．支持多種存儲引擎。
12.MySQL 是開源的，所以你不需要支付額外的費用。
13.MySQL 使用標準的SQL數據語言形式。
14.MySQL 對 PHP 有很好的支持，PHP是比較流行的 Web 開發語言。
15.MySQL是可以定製的，採用了GPL協議，你可以修改源碼來開發自己的 MySQL 系統。
16.在線 DDL/更改功能，數據架構支持動態應用程序和開發人員靈活性（5.6新增）
17.複製全局事務標識，可支持自我修復式集羣（5.6新增）
18.複製無崩潰從機，可提高可用性（5.6新增）
19.複製多線程從機，可提高性能（5.6新增）
20.3倍更快的性能（5.7[7]新增）
21.新的優化器（5.7新增）
22.原生JSON支持（5.7新增）
23.多源複製（5.7新增）
24.GIS的空間擴展[8]（5.7新增）
好噠，那知道了這些之後，我們接下來看調優，這也是在面試的過程中被經常問到的一些問題，而且隨着互聯網的發展，數據量的增大，不想引入大數據體系的，那只能在數據庫上下功夫了，那麼對於數據庫的調優，不知道各位覺得難嗎？其實真的不難，不信，看下面
MySQL調優思維導圖
看到這張思維導圖，從上往下，不知道在看這篇文章的你有沒有回想一下自己的知識體系中，這些方面是不是很清晰呢？
好，看完這句話，我的重點要來了，你在回想這些知識點的時候，是不是對你的知識點進行了一個回顧和梳理，查漏補缺，你也知道了自己知識點上的不足，是不是可以有針對性的進行學習呢？
我們以分庫和分表爲例去進行一個商討
分庫分表
1、水平分庫
概念：以字段爲依據，按照一定策略（hash、range等），將一個庫中的數據拆分到多個庫中。
結果：
- 每個庫的結構都一樣；
- 每個庫的數據都不一樣，沒有交集；
- 所有庫的並集是全量數據；
場景：系統絕對併發量上來了，分表難以根本上解決問題，並且還沒有明顯的業務歸屬來垂直分庫。
分析：庫多了，io和cpu的壓力自然可以成倍緩解。
2、水平分表
概念：以字段爲依據，按照一定策略（hash、range等），將一個表中的數據拆分到多個表中。
結果：
- 每個表的結構都一樣；
- 每個表的數據都不一樣，沒有交集；
- 所有表的並集是全量數據；
場景：系統絕對併發量並沒有上來，只是單表的數據量太多，影響了SQL效率，加重了CPU負擔，以至於成爲瓶頸。推薦：一次SQL查詢優化原理分析
分析：表的數據量少了，單次SQL執行效率高，自然減輕了CPU的負擔。
3、垂直分庫
概念：以表爲依據，按照業務歸屬不同，將不同的表拆分到不同的庫中。
結果：
- 每個庫的結構都不一樣；
- 每個庫的數據也不一樣，沒有交集；
- 所有庫的並集是全量數據；
場景：系統絕對併發量上來了，並且可以抽象出單獨的業務模塊。
分析：到這一步，基本上就可以服務化了。例如，隨着業務的發展一些公用的配置表、字典表等越來越多，這時可以將這些表拆到單獨的庫中，甚至可以服務化。再有，隨着業務的發展孵化出了一套業務模式，這時可以將相關的表拆到單獨的庫中，甚至可以服務化。
4、垂直分表
概念：以字段爲依據，按照字段的活躍性，將表中字段拆到不同的表（主表和擴展表）中。
結果：
- 每個表的結構都不一樣；
- 每個表的數據也不一樣，一般來說，每個表的字段至少有一列交集，一般是主鍵，用於關聯數據；
- 所有表的並集是全量數據；
場景：系統絕對併發量並沒有上來，表的記錄並不多，但是字段多，並且熱點數據和非熱點數據在一起，單行數據所需的存儲空間較大。以至於數據庫緩存的數據行減少，查詢時會去讀磁盤數據產生大量的隨機讀IO，產生IO瓶頸。
分析：可以用列表頁和詳情頁來幫助理解。垂直分表的拆分原則是將熱點數據（可能會冗餘經常一起查詢的數據）放在一起作爲主表，非熱點數據放在一起作爲擴展表。這樣更多的熱點數據就能被緩存下來，進而減少了隨機讀IO。拆了之後，要想獲得全部數據就需要關聯兩個表來取數據。
但記住，千萬別用join，因爲join不僅會增加CPU負擔並且會將兩個表耦合在一起（必須在一個數據庫實例上）。關聯數據，應該在業務Service層做文章，分別獲取主表和擴展表數據然後用關聯字段關聯得到全部數據。
好了，到這裏，分庫和分表的操作基本就完成了，不知道大家有沒有什麼感覺，如果知識只是單純的去看這些知識點，你能記住多久呢？反正如果我長時間不看，就忘了，，但是我不慫 啊，因爲我有這張圖，而且比展示出來的更加詳細，所以當我需要用到時候就可以看了，直接就可以拿出來看，哪怕只有10分鐘就夠了。
不知道你怎麼感覺，其實我覺得你也可以，當你學完之後，在我的這張知識圖譜上，把會的知識點進行整理，不會的知識點在學完之後也可以整理到這份圖譜中，即使後面用不到有所遺忘，但是當你需要這些資料的時候，比方說你要面試了，那你會覺得慌嘛？是不是拿出來這張圖就可以啊，想看那個知識點點開看一下就可以了。
其實，今天的標題是有一點不是特別準確，其實每一個程序員們都清楚，不僅僅是數據庫，其他 的技術也是這樣，從Java基礎（源碼等）---架構師---大數據----人工智能，哪怕你不從事這一行，難道就不能去學習了嗎？互聯網發展這麼快，天知道那天就能用到呢？
人無遠慮必有近憂，好了，兄弟們，時間已經很晚了，就到這裏吧
關注我，後期不斷更新新的文章，包括面試、技術、學習等技術，關注我，不迷路，有什麼問題，也可以在評論區或者私信和我交流
覺得文章寫的不錯的老鐵們，歡迎點贊+評論，
公衆號：Java架構師聯盟，每日更新技術好文
