MYSQL的表設計與使用

本篇內容主要講解“MYSQL的表設計與使用”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MYSQL的表設計與使用”吧!

一個表的設計，個人愚見，首先要看業務，以及你選擇的架構，業務量是大還是小，業務是互聯網性質的，還是傳統性質的，業務是可變化較大的，還是比較固話的，等等，當然可能還有更細分的，從數據庫的角度來看，你是準備使用哪種數據庫，決定是可以分庫分表，還是分區表，或者冷熱表，在或者使用特殊的某些小手段，來讓你的表更清爽一些。同時不同的數據庫也賦予表設計更多的余地，所以我一直在希望開發和DBA能緊密結合，因為開發大部分是不知道各種數據庫的門道，和一些奇特的功能，而DBA可能并未有開發人員的對業務理解的深刻，如果二者結合，則設計的表會比單方面設計的表要好的多。也更值得推敲。

下面就說說，在MYSQL 表設計中的一些見過的，小麻煩，以及如何化解。

1拿到的數據中，MYSQL的表竟然沒有主鍵，根據和開發人員交流，發現他們有一個很有趣的想法，認為沒有主鍵的表的插入速度會快，因為他們要要求插入的速度要快，而根據他們以往的ORACLE的經驗是這樣認為的。當時和他們解釋，他們提出ORACLE的表沒有主鍵會在表上默認產生ROWID，所以對這樣的信息記錄的表（弱業務）是可以這樣設計的，先不提在ORACLE  這樣是否OK，在MYSQL 中我只問了他們一個問題，“請問這個表還需要查詢嗎”，回答是當然。 

根據他們的回答，我建議，既然要查詢，則需要建立主鍵，或者退而求其次建立唯一索引。并解釋了為什么(MYSQL的表的原理，以及底層結構），開發人員表示認同，隨即添加主鍵。

其實之前也是遇到過這樣的情況，但當時解釋的角度就是一句，規章制度，軍規，或者在解釋MYSQL的復制必須要設置主鍵，等等。但開發人員給我的回饋是不是太好，這讓當時我的反思，在解決問題的時候要站在對方的角度，來處理，對方會更好的接受和理解，并且還會和你一條心的解決，因為這設計了他自己的利益。

2 在參與一個系統的設計時，開發人員將一個表的主鍵設置為多個列，根據業務邏輯來看，他這樣做是沒有問題的，地區編碼，加客戶編碼，加客戶的類型，是能決定這個表中客戶的唯一性，雖然從MYSQL本身的角度不建議這樣做，但開發人員提出，那業務已經這樣設計，你讓我怎么辦，這里面差一個字段，都不能確認具體的客戶的唯一性，而且業務也沒有打算給每一個客戶分配一個唯一的編碼。

到此即使你拿出軍規，或者數據庫原理來和開發講，也是無效，他也是受害者。現在關鍵的問題是你怎么來化解這個事情，而不是強硬的創造“對立面”。

解決方法1  和開發人員商量，是否可以創建遞增主鍵，按照INT 類型，而我們的區域，客戶類型，以及客戶ID，則作為唯一索引進行創建，開發人員表示可以考慮。

解決方法2  和開發人員商量，是否可以通過重新物理編碼的方式，通過三個字段的值進行運算后得出一個唯一值，將這個值作為主鍵，并且計算值的時候可以考慮一下順序性例如 

區域+ 用戶類型 + 用戶ID +數據插入時間 （可以到秒）--根據輸入的用戶量與時間的之間的比率。并且在表的字段中加入數據插入的時間，這樣雖然看上去比上面的方式麻煩，但可以解決查詢時的唯一性，也不需要建立唯一索引，通過主鍵可快速定位相對應的用戶。

最后的結果，開發選擇了第二種方法，其實大部分DBA 都是拿出，規則，規矩來進行限制，當然這本身是對的，這也是為系統正常運行來考慮的，但如果稍微站在對方的角度，來處理，可能效果預期會更好。

3 在開發一個系統的時候，大部分開發人員之前是沒有使用過MYSQL數據庫的，在表結構的設計，雖然之前提及過的一些MYSQL 特有的規范，但還是在數據庫的設計中發現了大量的主外鍵設計，隨即和開發人員溝通，發現開發人員的想法還是在三范式,3NF,以及表之間關聯性完整性，以及數據的不重復性考慮。后面和開發人員溝通，對當前使用的MYSQL的版本以及 Join 的MYSQL 操作原理進行了講解，開發人員表示理解，后面和開發人員將原來的表設計重新梳理，將一些頻繁查詢的數據匯總到一張表，或兩張表中，不在4-9張表進行JOIN 才能獲得數據，同時也對開發人員在改變設計后的繁瑣表示理解。

從溝通中也了解，程序員的想法，大多是根據3NF的影響，避免不同表中重復的字段，在查詢中通過多個表的關聯+條件，進行信息的輸出，與互聯網行業相比某些傳統的行業的邏輯會比較復雜，所以使用MYSQL 會讓程序在非數據庫層做的更多，想的更多。這也是部分程序員吐槽MYSQL 數據庫不好用的原因。

所以和在使用任何一種數據庫的時候，前提要以服務業務為中心，基于所使用的數據庫的原理進行發散，或混合行的思維方式，不能只死在一個數據庫，例如如果頻繁的更新狀態，但一行記錄或業務無論有多少次變化，但最后的變化的值是固定的，那是不是可以使用其他的數據庫（非RDS）來進行快速的狀態緩沖最終將結果刷入的到數據庫表中，避免由于頻繁更新和查詢產生的性能問題，等等這都是需要開發和DBA 進行溝通，利用互有的知識進行，以達到最大的優化和將問題消滅在系統設計的初期。

所以，合作能共贏，而軍規，規定等等都是一個范圍，而如果在這個范圍無法解決問題，則這個范圍是不是有問題，或者我們是否還能更進一步的提高自己的能力，利用各種手段維護軍規的同時，還能滿足業務，開發的需求，這就要看個人的能力，你會的越多，你解決問題的高度就會更高。相關與你有關的對立面就越少。

到此，相信大家對“MYSQL的表設計與使用”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！