MySQL調優表結構優化

1 合理使用范式和反范式

1.1 范式

遵循范式的優點：

范式化的更新通常比反范式要快。

當數據較好的范式化后，很少或者沒有重復的數據。

范式化的數據比較小，可以放在內存中，操作比較快。

遵循范式的缺點：

通常需要進行表關聯。

1.2 反范式

反范式優點：

所有的數據都在同一張表中，可以避免關聯。

可以設計有效的索引。

反范式缺點：

表格內的冗余較多，刪除數據時候會造成表有些有用的信息丟失。

1.3 如何選擇

在實際開發中很少能做到嚴格意義上的范式或者反范式，一般都是混合使用。

2 主鍵的選擇

2.1 代理主鍵和自然主鍵

主鍵一般可分為代理主鍵和自然主鍵：代理主鍵與業務無關，是無意義的數字序列；自然主鍵指事物屬性中的自然唯一標識。一般推薦使用代理主鍵，因為它們不與業務耦合，因此更容易維護。

2.2 問題：為什么使用自增id而不是UUID

2.2.1 從空間方面考慮

使用uuid（varchar）所占用的存儲空間一般都比int甚至bigint占用的存儲空間都要大。InnoDB的數據是按數據頁為單位來讀寫的，一個頁的大小是16kb。本來查詢某個范圍的數據，只需要加載一頁，現在需要查詢兩頁才能獲取完整結果。這意味著加載數據時，多了一次磁盤I/O。

2.2.2 從插入性能考慮

我們知道Mysql的索引樹是按索引列進行排序的，而如果我們用無序的uuid直接插入數據的話很可能會破壞這個平衡，而自增id則可以避免破壞這個平衡。

為了保持這個平衡，MYSQL在插入時uuid時肯定會進行二分查找，而二分查找的過程肯定需要對數據進行比較，這樣無疑就增加了成本。

還有一點，針對頁分裂，因為uuid的無序性，頁分裂時可能要將一部分數據移動到新頁中，這樣不僅消耗額外性能，也容易生成空間碎片。而使用自增id，則不會出現"將一部分數據移動至新頁"這種操作，因為本來就是有序的，直接在新頁往下寫就是了。

3 存儲引擎的選擇

MyISAM InnoDB

索引類型 非聚簇索引 聚簇索引

支持事務 否 是

支持表鎖 是 是

支持行鎖 否 是

支持外鍵 否 是

支持全文索引 是 是

適合操作類型 大量SELECT 大量INSERT、UPDATE、DELETE

4 適當的拆分

當我們的表中存在類似于TEXT或者是很大的VARCHAR類型的大字段的時候，如果我們大部分訪問這張表的時候都不需要這個字段，我們就該將其拆分到另外的獨立表中，以減少常用數據所占用的存儲空間。這樣做的一個明顯好處就是每個數據塊中可以存儲的數據條數可以大大增加，既減少物理 IO 次數，也能大大提高內存中的緩存命中率。

MySQL

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。