MySQL-性能優化-優化設計和設計原則

MySQL-性能優化-優化設計和設計原則

MySQL性能優化目的
如何合理的設計數據庫？
什麼樣的數據庫設計才能給後期DBA優化提供基石？

數據庫設計與程序設計的差別？

數據庫設計早期優化
1. 關係明確（理清表之間的關係，能夠經過冗餘的方式提升效率）
2. 節省空間（根據業務經驗，設置字段長短）
3. 提升效率

數據庫表開發流程

原型=>逐步完善（表的設計也是如此）

數據庫種類
1. 層級數據庫（註冊表） 如：Windows操做系統的核心就是一個註冊表，因爲配置項比較多，採用層級關係的數據存儲
2. 關係型數據庫 如：MySQL
3. 時序數據庫
4. 圖數據庫 如：最短路徑，地理信息
5. Key-value數據庫 如：Redis
6. 對象數據庫
7. BigTable數據庫

文件系統和數據庫系統之間的區別？
(1)文件系統用文件將數據長期保存在外存上，數據庫系統用數據庫統一存儲數據;
(2)文件系統中的程序和數據有必定的聯繫，數據庫系統中的程序和數據分離;
(3)文件系統用操做系統中的存取方法對數據進行管理，數據庫系統用DBMS統一管理和控制數據;
(4)文件系統實現以文件爲單位的數據共享，數據庫系統實現以記錄和字段爲單位的數據共享。

優化設計第一步

想要在表設計中節省空間，就必須精通各類數據類型的特色（能用在什麼業務上）、長度等。

int類型只增主鍵字段=>4字節=>每一個字節8位=>32位，在CPU加載一條指令的時候，4字節是和CPU寄存器的運算有關，如：64位，因爲直接的系統通常都是32位的，因此在運算4字節的數據是恰好的，效率最高，而現今咱們系統基本都是64位的時候，其實沒有更好的利用好CPU運算，因此在設計表字段建議，使用8字節的主鍵bigint，而不是直接使用int來作主鍵。

uuid作主鍵，字符類型作主鍵，在CPU的加載是須要消耗更多的運算過程

char(10) 無論該字段是否存儲數據，都佔10個字符的存儲空間
char(10) 同時存在一個坑，就是存儲abc數據後改數據庫字段的值爲「abc 7個空格 」，在精準查詢（where）就必須帶上後面的7個空格

varchar 不存的時候不佔空間，存多長數據就佔多少空間

優化設計第二步

如何合理的設計出符合三範式數據庫表?
1NF：列不可分。每一列都是不可分割的基本數據項，如這樣的設計就不合理，姓名（王五，wangwu）
2NF：1NF的基礎上面，非主屬性徹底依賴於主關鍵字，如學生姓名（非主屬性）就是依賴於學號（主屬性）的。
3NF：屬性不依賴於其它非主屬性 , 消除傳遞依賴，如這樣的設計就不合理，學號作主鍵，學生課程表（學號=課程），當學號修改，對應的課程表也須要修改，這就是屬於傳遞依賴
BCNF：符合3NF，每一個表中只有一個候選鍵
4NF：沒有多值依賴
因爲學號不能作主鍵，那用什麼作主鍵？首先就有這樣的規則：不要用業務規則來作主鍵，主鍵就應該和業務無關。
如常常用的的order_no（業務訂單號），即便是惟一的，也不建議作主鍵的，容易產生傳遞依賴的問題，這樣就不符合第三範式了。

優化設計第三步

數據庫優化策略
一、選擇小的數據類型
二、單獨設計主鍵，並考慮分佈式擴展
三、外鍵設計
（重要，咱們以前開發都是直接使用的弱外鍵來設置主外鍵關係，而實際項目中，若是要是刪除了主鍵對應的記錄後，外鍵表中的記錄是沒有刪除的，這樣對於數據庫的數據是很容易混亂的，不便於維護，那我要是使用的是強外鍵的方式，這樣直接刪除主鍵記錄，沒有刪除外鍵表中的記錄，這樣是要報錯的，這樣容易找到代碼上的問題，外鍵的設計能對於數據完整性有一個好的約束，當你開發的系統已經徹底不會出現數據不完整的問題的時候，你能夠考慮使用弱外鍵來關聯表操做，也同時會省去外鍵消耗，具體的設置外鍵方法查考博客：外鍵及其約束理解）
四、索引設計
（對於業務上的字段，那些須要字段須要創建索引？）
五、關聯關係表設計，多對一，多對多
六、讀寫頻繁的信息，與不頻繁的信息分開
（如在設計支付系統的時候，會同時存在訂單表和訂單記錄表，訂單表讀寫頻繁，而訂單記錄表就管理人員用，讀寫通常）
七、配置表，日誌表，定時任務表等
八、彙總表設計
（多表關聯查詢會很慢，還容易卡死的狀況，能夠考慮在業務上彙總，記錄到彙總表）

優化設計第四步

通過業務的沉澱，積累出一些設計思路或抽取出多項目的共同點，減小開發成本

一、通用型設計
例：人員，部門，角色
二、特別設計
附件，日誌，配置，監控等
三、存儲設計
類型劃分便於分區
四、一些附加字段
建立日期，修改日期，排序
五、流水錶
相似於日誌，但由業務處理結果組成，賬戶變更或業務處理的中間值

在設計數據庫的時候應當落實以下的原則
（一）下降對數據庫功能的依賴（如在業務上使用了MySQL特性，且這個特性是隻有MySQL存在的，對之後的數據庫遷移會帶來很大的麻煩）
（二）定義實體關係的原則
牽涉到的實體 識別出關系所涉及的全部實體。
全部權 考慮一個實體「擁有」另外一個實體的狀況。
基數 考量一個實體的實例和另外一個實體實例關聯的數量。
（三）列意味着惟一的值
若是表示座標（0,0），應該使用兩列表示，而不是將「0,0」放在1個列中。
（四）列的順序，可讀性問題
（五）定義主鍵和外鍵
數據表必須定義主鍵和外鍵（若是有外鍵）。
（六）選擇鍵
（七）是否容許NULL
任何值和NULL拼接後都爲NULL。
全部與NULL進行的數學操做都返回NULL。
引入NULL後，邏輯不易處理。
（八）規範化——範式
1NF
包含分隔符類字符的字符串數據。
名字尾端有數字的屬性。
沒有定義鍵或鍵定義很差的表。
2NF
多個屬性有一樣的前綴。
重複的數據組。
彙總的數據，所引用的數據在一個徹底不一樣的實體中。
BCNF- 「每一個鍵必須惟一標識實體，每一個非鍵熟悉必須描述實體。」
4NF
三元關係（實體:實體:實體）。
潛伏的多值屬性。（如多個手機號。）
臨時數據或歷史值。（須要將歷史數據的主體提出，不然將存在大量冗餘。）
（九）選擇數據類型
（十）優化並行
設計DB時就應該考慮到對並行進行優化，好比，timestamp類型。

在此我向你們推薦一個架構學習交流羣。交流學習羣號：575745314 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

命名規則
表名規則
一、要用前綴，但不要用無心義的前綴
二、下劃線分隔
三、全小寫
列名規則
一、通常不用前綴（當和關鍵詞衝突的能夠考慮加前綴區別）
二、下劃線分隔
三、全小寫

不論是表名設計仍是列名設計，都不要使用拼音來命名，過一段時間就徹底不記得了，就用英文，即便英語很差設計的時候也建議設置爲英文。