Mysql（一）Schema 數據類型優化 和索引基礎

前言

文本已收錄至個人GitHub倉庫，歡迎Star：github.com/bin39232820…
種一棵樹最好的時間是十年前，其次是如今
我知道不少人不玩qq了,可是懷舊一下,歡迎加入六脈神劍Java菜鳥學習羣，羣聊號碼：549684836 鼓勵你們在技術的路上寫博客

絮叨

爲啥要講Mysql呢？由於這個在面試也問得比較多，並且本身不少時候寫代碼用到mysql的時候，也沒有太過於注意一些東西，而後我想着把mysql的東西 好好整理一下，哈哈。而後慢慢來吧，從最基礎的開始，這個系列也是不中止系列。寫到哪算到哪 博主從學了mysql以後一直沒有系統的學習過mysql 此次爲了啃他 準備了

• 掘金小冊的 從根兒上理解mysql

  

  說實話這個確實很牛逼，基本上看第一遍的時候我都特麼以爲徹底看不懂，看第二遍才能稍微明白，這種文章適合反覆看，像我這個小白，唉，只能說菜的扣腳。
• mysql 45講

難度比上面的小點。

• 高性能mysql

技術總監點名要學習的，還不錯。

• 深刻淺出mysql

  

其實我寫博客，也就是記錄本身的學習過程，其實我是以爲本身仍是很菜的，在技術的路上 還處在 看山是山 的境界嗎，但願2年後看到本身寫的文章，內心會冒出一句，這是哪一個shabi寫的東西，哈哈，這說明，我這2年當中有進步嘛，好啦，你們一塊兒來跟我係統的學習學習mysql吧。

後續文章默認你們會簡單的crud，而且會用SQL語言，若是你連SELECT、INSERT這些單詞都沒據說過。那你得去學學基礎了。(固然寫博客的時候，博主也是這個水平的，因此我寫出來的文章可能水平不高，可是確定真實，由於我和你們同樣是慢慢學得)

Schema 和 數據類型優化

良好的邏輯設計和物理設計是高性能的基石，應該根據系統將要執行的查詢語句設計schema,這個須要本身好好權衡利弊。例如，反範式能夠加快查詢速度，可是同時也會使另外1一些查詢變慢。因此下面就介紹一些實用的經驗，數據庫類型的優化。

• 設計正確存儲數據的最小數據類型，更小的數據一般更快，由於它們佔用更少的磁盤，內存。和CPU
• 儘可能避免NULL,一般狀況下最好指定爲NOT NULL，除非真的須要存儲NULL。由於可爲NUll的列須要更多的存儲空間，在記錄索引的時候，可爲NUll的列須要多一個字節（後面文章會細細道來）
• 對於時間類型的選擇 DATETIME 和TIMESTAMP它們均可以存儲相同的時間類型，可是TIMESTAMP只使用DATETIME一半的存儲空間。因此儘可能選擇TIMESTAMP (而且它的默認值是不爲NULL)
• char 和varchar 這個得看本身業務需求了，若是你肯定你得字段的大小是百分之一百的，那你確定是用char,若是不肯定你就得用varchar 而且就是預估本身這個類型的長度。
• 對於bit 是不建議用的，好比說咱們業務中須要標識是否刪除，是否上架這種類型的（只有2種狀況的，也是建議使用tinyint來標識。
• 儘可能使用相同的數據類型存儲類似或者相關的值，尤爲是要在關聯查詢中使用的列
• 當心使用ENUM，雖然他們很好用。可是不要濫用。
• 儘可能作到避免過分設計，例如會致使及其複雜的查詢schema設計，或者有不少列的表設計。

範式是好的，可是反範式有時也是必須的，作過微服務開發的都知道，有時候咱們冗餘一些字段，能夠爲咱們的業務帶來更快的查詢，可是咱們更新的時候，就必需要多維護多一張表，因此對於咱們讀多寫少的場景，我以爲冗餘多一個字段也是沒有問題的。對於範式和反範式的混用，得看具體的業務，仁者見仁，智者見智。通過你們多年來的實踐經驗得來的纔是最真實的

索引基礎

什麼是索引

在關係數據庫中，索引是一種單獨的、物理的對數據庫表中一列或多列的值進行排序的一種存儲結構，它是某個表中一列或若干列值的集合和相應的指向表中物理標識這些值的數據頁的邏輯指針清單。索引的做用至關於圖書的目錄，能夠根據目錄中的頁碼快速找到所需的內容。

Tips

最近在作sql優化，其實sql咱們作sql優化的時候第一步想到確定是加索引，好比某一個 SQL 查詢比較 慢，分析完緣由以後，你可能就會說「給某個字段加個索引吧」之類的解決方案。但到底什麼是 索引，索引又是如何工做的呢？

常見的索引類型

索引的出現是爲了提升查詢效率，可是實現索引的方式卻有不少種，因此這裏也就引入了索引模 型的概念。能夠用於提升讀寫效率的數據結構不少，這裏我先給你介紹三種常見、也比較簡單的 數據結構，它們分別是哈希表、有序數組和搜索樹。

哈希表

其實這個能夠直接對比Java的HashMap，還算是比較簡單 底層實現能夠是數組+鏈表的這種數據結構，哈希的思路很簡單，把值放在數組裏，用一個哈希函數把 key 換 算成一個肯定的位置，而後把 value 放在數組的這個位置。 不可避免地，多個 key 值通過哈希函數的換算，會出現同一個值的狀況。處理這種狀況的一種 方法是，拉出一個鏈表。

哈希表的特色就是能夠快速的精確查詢，可是不支持範圍查詢。它適用於等值查詢的地方

有序數組

有序數組在等值查詢和範圍查詢場景中的性能就都很是優秀 ，可是不合適更新，由於更新的時候就很是的耗費時間了，因此這種數據結構只能適合靜態數據，你好比你大學四樓泡的妹子。哈哈已經這個是永遠也不會改變的。有就是有，沒有就算沒有。。。

搜索樹

搜索數結構，還算蠻多的

• 二叉數
  • 它的話，搜索效率仍是不錯的，可是他的時間複雜度是O(log(N))，爲了維持這個時間複雜度，更新的時間複雜度也得是O(log(N))，那就得保持這棵樹是徹底平衡二叉樹了。
• 平衡二叉樹
  • 這個也是同樣的，它的樹高會很高，因此也不是那麼適合作mysql的存儲結構
• B數
  • B樹中的一個節點能夠存儲多個元素。
• B+數
  • B+樹是B樹的升級版，只是把非葉子節點冗餘一下，這麼作的好處是爲了提升範圍查找的效率。

N 叉樹因爲在讀寫上的性能優勢，以及適配磁盤的訪問模式，已經被普遍應用在數據庫引擎中了。數據庫底層存儲的核心就是基於這些數據模型的。每碰到一個新數據庫，咱們須要先關注它的數據模型，這樣才能從理論上分析出這個數據庫的適用場景。 對於數據結構和算法這門課，到時候我確定也得過一下的這些纔是軟件工程的基礎嘛。這裏就不一一細說了。

結尾

今天就稍微介紹了一下下哈。咱們下章繼續再戰，對了若是須要mysql上面這幾樣學習質料的話，能夠加qq羣下載，你們一塊兒從小白開始學mysql,羣裏還蠻好玩的，對於初學着來講，由於咱們不是大神，都是小白，相互學習。

平常求贊

好了各位，以上就是這篇文章的所有內容了，能看到這裏的人呀，都是真粉。

創做不易，各位的支持和承認，就是我創做的最大動力，咱們下篇文章見

六脈神劍 | 文 【原創】若是本篇博客有任何錯誤，請批評指教，不勝感激 ！