1.過分的反正規化化為表建立太多的列
我們在設計資料庫的結構時，比較容易犯的第乙個錯誤就是對錶進行了過分的反正規化化的設計，這就容易造成了表中的列過多，雖然說mysql允許為乙個表建立很多的列，但是由於mysql的外掛程式式架構的原因，前面部落格已經有介紹，mysql的伺服器層和儲存引擎層是分離的，mysql的儲存引擎api工作時需要把伺服器層和儲存引擎層之間通過緩衝格式來拷貝資料，然後在伺服器層將緩衝層的資料解析成各個列，這個操作過程成本是非常高的，特別是對於myisam的變長結構，和innodb這種行結構在解析時還必須進行轉換，這個轉換的成本呢就依賴於列的數量，所以，如果乙個表的列過多，在使用這個表時就會帶來額外過多的cpu消耗。所以在進行表設計的時候一定要注意，不要把錶相關的所有列都放在乙個表中，而是要按照正規化化適當的對錶進行拆分，關於什麼是正規化化，會另外的詳細介紹。
2.過分的使用正規化化設計造成了太多的表關聯
對資料庫的設計過分的使用了正規化化設計的思路，對於任何的查詢都要關聯很多個表，通過前面的介紹，我們知道對mysql進行表關聯查詢成本是非常高的，而且效能也會隨著關聯表的增加而下降，所以呢mysql對錶關聯的數量進行了限制，mysql最多隻可以關聯61個表，這個限制呢雖然對於大多數應用來說已經足夠了，但是我們為了mysql的效能還是要儘量減少關聯的表，關聯的表數量最好在10個以內，這就要求我們在進行資料庫設計時候要進行適當的反正規化化設計，把經常使用的兩個小表合成乙個大表，這樣做對提公升資料庫的效能和sql查詢的效能都是很有幫助的 。
3.在oltp環境中使用不恰當的分割槽表
分割槽表是乙個好東西，可以幫助我們把乙個大表在物理儲存上按照分割槽鍵分成多個小表，這裡要注意了，分割槽表和我們常說的分庫分表是有區別的，分割槽表是在同乙個資料庫例項下進行的，而物理儲存上分成多個小表但是在使用時邏輯上還是使用乙個表；而分庫分表所要做的操作不止是在物理上進行拆分而且邏輯上也會拆分多個表，而且分庫分表後多個表通常不是在乙個資料庫例項下的。在使用分割槽表時，分割槽鍵的選擇非常關鍵，如果分割槽鍵的選擇不恰當，就會造成查詢時跨多個分割槽查詢，這樣不僅不會提公升資料庫的效能，而且還會降低資料庫的查詢效能，所以建議在oltp環境中使用分割槽表一定要注意，分割槽表最好還是在olap環境使用，或者對於一些日誌表使用還是比較合適的。
4.使用外來鍵約束保證事務的完整性
我們都知道innodb儲存引擎是事務型儲存引擎，它是支援事務和外來鍵的，所以很多開發人員喜歡使用外來鍵約束來保證資料的完整性，但是這樣的效率是非常低的，因為在對使用外來鍵的表進行修改時，mysql都會對外鍵約束來進行檢查，這樣呢就帶來了額外的鎖的開銷，降低了資料庫修改的效率；另外使用外來鍵，在進行資料庫備份、恢復或者手動進行資料歸檔維護也會有問題，比如：我們不能使用truncate table對錶快速的進行清空操作， 只能使用delete from進行，這樣在主從複製的環境下對乙個大表的資料環境清理複雜度就會變得很高，所以強烈建議不要使用外來鍵約束，但是在關聯鍵上建立相關的索引還是必須的
mysql 資料庫設計 MySQL 資料庫設計總結
本文由雲 社群發表 規則 1 一般情況可以選擇 myisam 儲存引擎，如果需要事務支援必須使用 innodb 儲存引擎。注意 myisam 儲存引擎 b tree 索引有乙個很大的限制 參與乙個索引的所有欄位的長度之和不能超過 1000 位元組。另外 myisam 資料和索引是分開，而 innod...
mysql考勤資料庫設計 mysql 資料庫設計
正規化 大概有8種正規化，遵循前三個一般資料庫就沒有問題 1 列不能再拆分 比如一列中有姓名，又有性別，就是沒有遵循這一條正規化 order id product id price quantity product name 111 11 123 good pen order id 和 produc...
mysql相簿資料庫設計 mysql資料庫的設計
資料庫的設計有乙個嚴謹的流程，根據流程製作乙個完整的資料庫，可以省去很多的時間，也可以最大程度上與客戶的想法契合。需求分析階段 分析客戶的業務和資料處理需求 概要設計階段 設計資料庫的e r模型圖，確認需求資訊的正確和完整 詳細設計階段 應用三大正規化審核資料庫結構 編寫階段 物理實現資料庫，編碼實...