性能優化（數據庫設計原則）

優化設計

數據庫設計

數據庫設計是一個軟件項目成功的基石 。數據庫設計也是門學問 。
在項目早期由開發者進行數據庫設計（後期調優須要DBA ） 。一 個精通OOP 和ORM 的開發者，設計的數據庫每每更爲合理，更能適應需求的 變化。由於 數據庫的規範化，與OO 的部分思想雷同（如內聚）。而DBA ，設計的數據庫的優點是能將DBMS 的能力發揮到極致，可以使用SQL 和DBMS 實現不少程序實現的邏輯，與開發者相比，DBA 優化過的數據庫更爲高效和穩定 。

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

數據庫設計早期優化

不要把它僅僅當成一個存儲的功能
1 、關係明確
2 、節省空間
三、提升效率

設計原則

數據庫種類

數據庫特色

效率與空間

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

文件系統和數據庫系統之間的聯繫：
(1)均爲數據組織的管理技術;
(2)均由數據管理軟件管理數據，程序與數據之間用存取方法進行轉換;
(3)數據庫系統是在文件系統的基礎上發展而來的。

優化設計第一步

精通數據類型

優化設計第二步

範式1NF，2NF，3NF

1NF： 列不可分。每一列都是不可分割的基本數據項
2NF：1NF的基礎上面，非主屬性徹底依賴於主關鍵字
3NF：屬性不依賴於其它非主屬性 , 消除傳遞依賴
BCNF ：符合3NF ，每一個表中只有一個候選鍵
4NF：沒有多值依賴

優化設計第三步

認知

一、選擇小的數據類型
二、單獨設計主鍵，並考慮分佈式擴展
三、外鍵設計
四、索引設計
五、關聯關係表設計，多對一，多對多
六、讀寫頻繁的信息，與不頻繁的信息分開
七、配置表，日誌表，定時任務表等
八、彙總表設計

優化設計第四步

套路

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

Codd的RDBMS12法則

Edgar Frank Codd（埃德加·弗蘭克·科德）被譽爲「關係數據庫之父」，並由於在數據庫管理系統的理論和實踐方面的傑出貢獻於1981年獲圖靈獎。在1985年，Codd 博士發佈了12條規則，這些規則簡明的定義出一個關係型數據庫的理念，它們被做爲全部關係數據庫系統的設計指導性方針。
1. 信息法則 關係數據庫中的全部信息都用惟一的一種方式表示——表中的值。
2. 保證訪問法則 依靠表名、主鍵值和列名的組合，保證能訪問每一個數據項。
3. 空值的系統化處理 支持空值（NULL），以系統化的方式處理空值，空值不依賴於數據類型。
4. 基於關係模型的動態聯機目錄 數據庫的描述應該是自描述的，在邏輯級別上和普通數據採用一樣的表示方式，即數據庫必須含有描述該數據庫結構的系統表或者數據庫描述信息應該包含在用戶能夠訪問的表中。
5. 統一的數據子語言法則 一個關係數據庫系統能夠支持幾種語言和多種終端使用方式，但必須至少有一種語言，它的語句可以一某種定義良好的語法表示爲字符串，並能全面地支持如下全部規則：數據定義、視圖定義、數據操做、約束、受權以及事務。（這種語言就是SQL)
6. 視圖更新法則 全部理論上能夠更新的視圖也能夠由系統更新。
7. 高級的插入、更新和刪除操做 把一個基礎關係或派生關係做爲單個操做對象處理的能力不只適應於數據的檢索，還適用於數據的插入、修
改個刪除，即在插入、修改和刪除操做中數據行被視做集合。
8. 數據的物理獨立性 無論數據庫的數據在存儲表示或訪問方式上怎麼變化，應用程序和終端活動都保持着邏輯上的不變性。
9. 數據的邏輯獨立性 當對錶作了理論上不會損害信息的改變時，應用程序和終端活動都會保持邏輯上的不變性。
10. 數據完整性的獨立性 專用於某個關係型數據庫的完整性約束必須能夠用關係數據庫子語言定義，並且能夠存儲在數據目錄中，而非程序中。
11. 分佈獨立性 無論數據在物理是否分佈式存儲，或者任什麼時候候改變分佈策略，RDBMS的數據操縱子語言必須能使應用程序和終端活動保持邏輯上的不變性。
12. 非破壞性法則 若是一個關係數據庫系統支持某種低級（一次處理單個記錄）語言，那麼這個低級語言不能違反或繞過更高級語言（一次處理多個記錄）規定的完整性法則或約束，即用戶不能以任何方式違反數據庫的約束。

落實這些原則

（一）下降對數據庫功能的依賴

（二）定義實體關係的原則

牽涉到的實體 識別出關系所涉及的全部實體。

全部權 考慮一個實體「擁有」另外一個實體的狀況。

基數 考量一個實體的實例和另外一個實體實例關聯的數量。

（三）列意味着惟一的

值若是表示座標（0,0），應該使用兩列表示，而不是將「0,0」放在1個列中。

（四）列的 順序，可讀性問題

（五）定義主鍵和外鍵

數據表必須定義主鍵和外鍵（若是有外鍵）。

（六）選擇鍵

（七）是否容許NULL

任何值和NULL拼接後都爲NULL。全部與NULL進行的數學操做都返回NULL。引入NULL後，邏輯不易處理。

（八）規範化—— 範式

1NF
包含 分隔符類字符的字符串數據。
名字尾端有數字的屬性。
沒有定義鍵或鍵定義很差的表。
2NF
多個屬性有一樣的前綴。
重複的數據組。
彙總的數據，所引用的數據在一個徹底不一樣的實體中 。
BCNF-  「 每一個鍵必須惟一標識實體，每一個非鍵熟悉必須描述實體。 」
4NF
三元關係（實體: 實體: 實體）。
潛伏的多值屬性。（如多個手機號。）
臨時數據或歷史值。（須要將歷史數據的主體提出，不然將存在大量冗餘。）

（九）選擇 數據類型

（十）優化 並行
設計DB時就應該考慮到對並行進行優化，好比，timestamp類型。

 

命名規則

表名規則
1 、要用前綴，但不要用無心義的前綴
2 、下劃線分隔
3 、全小寫
列名規則
1 、通常不用前綴
2 、下劃線分隔
 

設計案例

鍵設計

物理主鍵，好建索引，消除傳遞依賴
主鍵類型，普通系統是int 或bigint ，效率問題
Uuid ，容量問題，防碰撞
取消全部的聯合主鍵（課程表中：年級+ 課程名）

索引設計

B-Tree 索引是 MySQL 數據庫中使用最爲頻繁的索引類型，除了 Archive 存儲引擎以外的其餘全部的存儲引擎都支持B-Tree 索引。不只僅在 MySQL 中是如此，實際上在其餘的不少數據庫管理系統中B-Tree 索引也一樣是做爲最主要的索引類型，這主要是由於 B-Tree 索引的存儲結構在數據庫的數據檢索中有很是優異的表現

Hash 索引結構的特殊性，其檢索效率很是高，索引的檢索能夠一次定位，不像B-Tree 索引須要從根節點到枝節點，最後才能訪問到頁節點這樣屢次的IO訪問，因此 Hash 索引的查詢效率要遠高於 B-Tree 索引。

普通索引：最基本的索引，沒有任何限制
惟一索引：與"普通索引"相似，不一樣的就是：索引列的值必須惟一，但容許有空值。
主鍵索引：它是一種特殊的惟一索引，不容許有空值。
全文索引：僅可用於 MyISAM 表，針對較大的數據，生成全文索引很耗時好空間。
組合索引：爲了更多的提升mysql效率可創建組合索引，遵循」最左前綴「原則。

覆蓋索引(Covering Indexes)

聚簇索引(Clustered Indexes)
聚簇索引保證關鍵字的值相近的元組存儲的物理位置也相同（因此字符串類型不宜創建聚簇索引，特別是隨機字符串，會使得系統進行大量的移動操做），且一個表只能有一個聚簇索引。由於由存儲引擎實現索引，因此，並非全部的引擎都支持聚簇索引。目前，只有solidDB和InnoDB支持。

非 聚簇 索引
二級索引葉子節點保存的不是指行的物理位置的指針，而是行的主鍵值。這意味着經過二級索引查找行。InnoDB對主鍵創建聚簇索引。若是你不指定主鍵，InnoDB會用一個具備惟一且非空值的索引來代替。若是不存在這樣的索引，InnoDB會定義一個隱藏的主鍵，而後對其創建聚簇索引 。通常來講，DBMS都會以聚簇索引的形式來存儲實際的數據，它是其它二級索引的基礎

表附加字段設計

經常使用：
建立時間：create_at
修改時間：update_at
排序：sn
有時用：
說明：desc，remark
備選字段：opts_1，opts_2….

字典表設計

字典表與系統配置表的區別

字典表示例
經常使用數據的常量化，消費類型，支付類型，物品類型（含層級）

系統配置表示例
各模塊功能參數的常量化，key-value

附件表設計

存儲位置
類型
用途
使用次數
下載次數

層級結構表設計

父子層級，parent_id
表內劃分層級
表外劃分層級
最快檢索設計

流程表設計

流程主表
任務子表
業務表關聯

冗餘設計

反範式

適當冗餘
一、借鑑覆蓋索引的思路，在表內直接放經常使用的字段
二、提取相關數據，製做彙總表
三、第3NF的違反
四、程序級別的冗餘或緩存
五、不要寫觸發器，不要寫存儲過程

分表分庫

•性能：能輕鬆面對海量數據和高併發的請求處理，好的分佈式數據庫能作到90%以上的線性增加能力；
•靈活性、彈性：現代的系統的業務和使用場景變化很快，用戶的增加也有不少不肯定因素。彈性擴容就很是重要。分佈式數據庫自己有Cloud-Ready的特性，能很容以經過添加設備擴容知足需求，而不須要影響開發；
•多中心、多活：這點在大型應用中很常見，分佈式數據庫就更容易實現這個功能，固然這裏涉及到分佈式數據庫的同步和一致性的能力，這也是判斷分佈式數據庫好壞的一個重要指標。
•讀寫分離：主從節點都能發揮做用；例如巨杉SequoiaDB數據庫，能在一組三副本的複製組上實現OLTP，NoSQL應用，OLAP多種應用場景同時使用。
•低成本：x86服務器，SATA存儲（部分能夠用SSD），加上較好的網絡帶寬就能夠了。

1.水平分區：基本對1個或多個鍵的水平哈希，加強數據的並行處理能力來提升性能； 2.垂直分區：和過去的Partition很像，對數據進行有含義的拆分； 3.混合分區：水平分區和垂直分區共同使用。