重新認識Mysql之冗餘字段的利與弊
在設計數據庫時，我們往往依照數據庫的範式降低數據間的冗餘度，但是冗餘字段就像是把雙刃劍，在業務需求上,有效的增加數據的冗餘度，還可以提高數據的訪問效率。
什麼是冗餘字段?
個人理解爲多張表中一致重複出現的字段,例如users表存在字段B,Wallet表也存在字段B,兩張表中該字段業務.
利:爲什麼要用冗餘字段
1.空間換時間
當我們遇到數據量非常大的表時候,這時去做表的關聯查詢(Join)是非常雖然消耗系統性能的,甚至可能會出現數據庫連接超時,crash等問題,這時就需要進行冗餘設計,將部分字段冗餘到關聯表中,避免大表之間的關聯查詢,提高更快的響應速度.
2.業務快照
在電商系統開發中,交易場景大部分是數據快照.
用戶下單時的收貨人、地址、商品名稱、商品描述、價格等字段,若採用關聯表的設計,商品A在用戶下單後發生了更新的話,再去進行關聯查詢就會導致和用戶操作時的數據不一致,則會產生交易糾紛行爲.
如:商品A 今天特價是100元,明天恢復原價200,用戶A今天下單消費了100元,但是明天價格進行恢復了,用戶申請了退款,需要系統退款200元,顯然是不合理的存在.
爲了系統的更健壯的運行服務用戶,我們則需要進行設計冗餘字段,來保證我們一些服務的可靠性.
弊:爲什麼不用冗餘字段
系統開銷大,維護成本高
當一張表上出現多個冗餘字段時,每次更新某條記錄,爲了保證數據一致性,每次都需要去更新這些冗餘字段,增加了系統開銷和提高了維護成本.
數據一致性
當冗餘字段使用的多了,數據一致性就難以保證,爲了保證一致性就會產生很大的性能開銷,如果某些冗餘字段是採用人工維護(開發人員),數據一致性就會難以得到保障.
比如:某動態實際評論3條,冗餘字段卻顯示了15,這樣就會產生剩下的評論去哪了的問題.
空間的代價
表A存在5個冗餘字段,隨着業務量增長,表A每日新增數據1000萬,久而久之這些冗餘字段就會成爲你儲存部分的硬傷.
如何平衡冗餘的設計
1. 遵循第三範式3NF,儘量減少冗餘字段,不隨便使用冗餘字段.
2. 只在關鍵業務數據使用冗餘字段,會讓數據庫執行性能更高、更快
3. 根據業務需求決定是否使用冗餘字段,統計型字段可以使用json結構儲存或建立冗餘數據表,通過策略來維護和更新