互聯網mysql表設計

互聯網數據存儲層，若是使用到關係型的數據庫，不少公司都會採用mysql。同理傳統軟件的mysql使用率也是很高，怎麼設計很好的數據庫表結構，每一個人都有本身的準則和標準。也許根據對應的業務需求不一樣也會有所不一樣。這裏對一些經驗來總結。

表字段的命名，要名如其意，而且儘可能的簡潔，由於這部份內容一樣是須要存儲的。

單表若是字段特別多，此時要考慮拆分表，根據數據類型或者業務類型來拆分。好比每一個系統都有的用戶表，用戶的核心數據放在一個表中，用戶的一些初始化信息，只有在第一次註冊時填的內容放在一個表中，用戶可能頻繁修改的一些字段放在一個表中。不只達到數據的拆分，並且對數據庫存儲的自己的空間進行了優化，而且根據數據的不一樣能夠創建對應的索引，增長查詢效率。

表字段類型的選擇，表中會有不少不一樣類型的字段內容，固然咱們設計表的時候確定會設計到字典表，對於一些定性而且是可選的內容是咱們都將使用字典來存儲，對於mysql而言你就可使用佔用空間很小的字段類型來設置該字段TINYINT，有符號的範圍是-128到127，無符號的範圍是0到255。不只選擇了合適的字段類型減輕了數據存儲空間，而且增長了可擴展性。這點能夠參考mysql的官方文檔來根據需求設定字段類型。對於時間類型的選擇，首先你要考慮你的服務器使用的時間精確度，不一樣的數據類型須要的空間也是不同的。

表字段冗餘的問題，這個是要和具體的業務關聯起來的，在設計數據庫的時候雖然要求咱們儘可能的減小數據冗餘，可是在有些業務場景下咱們須要頻繁的關聯另一個表查詢對應表字段的一個內容，數據量小几百萬都是問題不大，若是數據量是遞增的，還有若是遇到分庫分表，每次錯跨表查詢或者跨庫查詢都是須要消耗時間和空間的，此時合適的冗餘會增長業務系統的性能，帶來的問題同樣是很大的，是否須要實時的更新，原數據修改了怎麼辦？這個不是絕對的，須要考慮具體的業務需求。

數據量大的關聯查詢，此時咱們必定要杜絕關聯查詢，能夠在代碼級別進行數據的拼接，實現關聯查詢的效果。