MySQL 性能優化，優化設計及設計原則解讀
如何合理的設計數據庫？
什麽樣的數據庫設計才能給後期DBA優化提供基石？
數據庫設計與程序設計的差異？
數據庫設計早期優化
-
關系明確（理清表之間的關系，可以通過冗余的方式提高效率）
-
節省空間（根據業務經驗，設置字段長短）
- 提高效率
數據庫表開發流程
原型=>逐步完善（表的設計也是如此）
數據庫種類
-
層級數據庫（註冊表） 如：Windows操作系統的核心就是一個註冊表，由於配置項比較多，采用層級關系的數據存儲
-
關系型數據庫 如：MySQL
-
時序數據庫
-
圖數據庫 如：最短路徑，地理信息
-
Key-value數據庫 如：Redis
-
對象數據庫
- 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（業務訂單號），即使是唯一的，也不建議做主鍵的，容易產生傳遞依賴的問題，這樣就不符合第三範式了。
優化設計第三步
數據庫優化策略
1、選擇小的數據類型
2、單獨設計主鍵，並考慮分布式擴展
3、外鍵設計
（重要，我們之前開發都是直接使用的弱外鍵來設置主外鍵關系，而實際項目中，如果要是刪除了主鍵對應的記錄後，外鍵表中的記錄是沒有刪除的，這樣對於數據庫的數據是很容易混亂的，不便於維護，那我要是使用的是強外鍵的方式，這樣直接刪除主鍵記錄，沒有刪除外鍵表中的記錄，這樣是要報錯的，這樣容易找到代碼上的問題，外鍵的設計能對於數據完整性有一個好的約束，當你開發的系統已經完全不會出現數據不完整的問題的時候，你可以考慮使用弱外鍵來關聯表操作，也同時會省去外鍵消耗，具體的設置外鍵方法查考博客：外鍵及其約束理解）
4、索引設計
（對於業務上的字段，那些需要字段需要建立索引？）
5、關聯關系表設計，多對一，多對多
6、讀寫頻繁的信息，與不頻繁的信息分開
（如在設計支付系統的時候，會同時存在訂單表和訂單記錄表，訂單表讀寫頻繁，而訂單記錄表就管理人員用，讀寫一般）
7、配置表，日誌表，定時任務表等
8、匯總表設計
（多表關聯查詢會很慢，還容易卡死的情況，可以考慮在業務上匯總，記錄到匯總表）
優化設計第四步
經過業務的沈澱，積累出一些設計思路或抽取出多項目的共同點，減少開發成本
1、通用型設計
例：人員，部門，角色
2、特別設計
附件，日誌，配置，監控等
3、存儲設計
類型劃分便於分區
4、一些附加字段
創建日期，修改日期，排序
5、流水表
類似於日誌，但由業務處理結果組成，帳戶變動或業務處理的中間值
在設計數據庫的時候應當落實如下的原則
（一）降低對數據庫功能的依賴（如在業務上使用了MySQL特性，且這個特性是只有MySQL存在的，對以後的數據庫遷移會帶來很大的麻煩）
（二）定義實體關系的原則
牽涉到的實體 識別出關系所涉及的所有實體。
所有權 考慮一個實體“擁有”另一個實體的情況。
基數 考量一個實體的實例和另一個實體實例關聯的數量。
（三）列意味著唯一的值
如果表示坐標（0,0），應該使用兩列表示，而不是將“0,0”放在1個列中。
（四）列的順序，可讀性問題
（五）定義主鍵和外鍵
數據表必須定義主鍵和外鍵（如果有外鍵）。
（六）選擇鍵
（七）是否允許NULL
任何值和NULL拼接後都為NULL。
所有與NULL進行的數學操作都返回NULL。
引入NULL後，邏輯不易處理。
（八）規範化——範式
1NF
包含分隔符類字符的字符串數據。
名字尾端有數字的屬性。
沒有定義鍵或鍵定義不好的表。
2NF
多個屬性有同樣的前綴。
重復的數據組。
匯總的數據，所引用的數據在一個完全不同的實體中。
BCNF- “每個鍵必須唯一標識實體，每個非鍵熟悉必須描述實體。”
4NF
三元關系（實體:實體:實體）。
潛伏的多值屬性。（如多個手機號。）
臨時數據或歷史值。（需要將歷史數據的主體提出，否則將存在大量冗余。）
（九）選擇數據類型
（十）優化並行
設計DB時就應該考慮到對並行進行優化，比如，timestamp類型。
命名規則
表名規則
1、要用前綴，但不要用無意義的前綴
2、下劃線分隔
3、全小寫
列名規則
1、一般不用前綴（當和關鍵詞沖突的可以考慮加前綴區別）
2、下劃線分隔
3、全小寫
不管是表名設計還是列名設計，都不要使用拼音來命名，過一段時間就完全不記得了，就用英文，即使英語不好設計的時候也建議設置為英文。
MySQL 性能優化，優化設計及設計原則解讀