MySQL資料庫設計經驗分享

其實這個經驗分享並不僅僅針對MySQL，之所以加上這個關鍵字其實是為了給搜尋引擎看的，呵呵。這篇文章的目標是為了拓寬新手的思路，對於老鳥可能沒什麼幫助了。

文章主要涉及以下方面的內容：

1. 資料完整性約束的意義：資料的第一道防線；

2. 避免冗餘欄位：請不要認為這是一種彈性或者靈活性的體現；

3. 請儘可能的收集資料：這是一種境界；

4. 為什麼建立索引：不僅僅是速度；

5. 事務、觸發器與儲存過程：這是一扇門；

資料完整性約束的意義

很多新手建立的資料庫非常的簡單，一堆欄位扔進去就搞定了，反正指令碼會搞定一切。但是，你有沒有反思過一個問題，寫指令碼的也是人，是人就會犯錯誤，犯了錯誤就可能搞亂資料，而資料是一切應用的基礎。因此，我建議你們能夠靜下來，細心的，花費更多的時間來研究如何更好地設計資料庫結構。

主鍵是必須的

這是我的第一個建議，每個表必須具有主鍵，而且最好是使用單獨的一個欄位作為主鍵，這樣從根源上扼殺了出現兩條完全相同的資料的可能性。

你可能需要額外的唯一鍵

例如使用者資訊表中，除了使用者編號以外，其登入名稱也應該是唯一的，不要指望以後可以在程式中處理這個情況，現在就做，只要把它標記為唯一鍵，就算程式中忘了判斷也不會讓錯誤的資料被儲存進來。

欄位的型別和長度

請努力使用與資料匹配的型別和適當的長度，雖然你可以把時間儲存為varchar型別，但是明顯還是datetime型別更好，因為你不可能把2013-02-30之類的日期儲存到datetime型別的欄位中。欄位的長度也是需要考慮的，過長雖然比過短帶來的麻煩小很多，但是浪費了很多空間。

預設值

儘量為欄位設定預設值，例如欄位is_read用來表示使用者是否已經閱讀過這條留言，1表示已讀，請為它設一個預設值0來代表未讀，而不是在日後的查詢語句中通過is_read <> 1或者is_read = IS NULL OR is_read = 0來判斷。

允許為NULL嗎？

這個問題需要思考，而不是一概允許或一概不允許這種模式化的判定。同時，建議不要將NULL作為一個特殊的值來使用。

外來鍵約束是必不可少的

你必須理解和開始使用外來鍵，並且明白外來鍵約束的用法，這是維護資料完整性很重要的一環。建立外來鍵的同時你會對程式的業務邏輯有更清晰的認識。正確的使用它防止誤刪具有依存關係的資料，同時通過級聯刪除保證在刪除的時候不留下任何垃圾。

避免冗餘欄位

千萬不要認為冗餘欄位能夠使資料表更有彈性、更靈活。首先來說冗餘的欄位必然都是允許為NULL的，因為沒有適合的程式碼為這些欄位賦值（如果有的話那就不是冗餘欄位了，對嗎）。這隻會增加資料表的體積。事實上修改表結構僅需幾分鐘，真正的麻煩還是來自於為新欄位新增相應的業務邏輯。

而且事物總是在變化的，今天你覺得未來可能會用到這個欄位，但是可能下個星期就不這麼想了，一個月之後你根本不記得當初留了這麼一個欄位。所以，刪了吧。

儘可能的收集資料

其實這有點跑題，因為這不僅僅是資料庫設計的事兒，程式設計師可能也要付出一些時間。我一貫的觀點就是“資料是一切應用的基礎”，儘量的收集它們，以後也許會有用（如果這個應用有一個長遠的預期的話，否則你可以忽略這點）。

我無法想象Google，百度或者淘寶明天會做什麼，但是我能肯定它們的業務調整的依據就是來自這些捕獲的資料。

儘可能的收集資料是指在不增加使用者操作指令的前提下儘可能的收集一些相關資訊。比如各種時間、瀏覽頁面的軌跡等等。我甚至懷疑以後某些應用會收集使用者擊鍵頻率這樣的資訊，然後利用它來檢測賬號是否被盜。

此外，我覺得應該儘量在插入/修改/刪除資料的時候多做一些事情，相對來說，這些操作不那麼頻繁，而且單次操作的資料量也更小。不要將壓力都留給查詢語句。例如，如果你的程式中需要使用類似SELECT *, SUM(`point`) AS `total_point` FROM `table` GROUP BY `user_id`的語句的話，不妨考慮為這個表增加一個total_point欄位。

為什麼建立索引

如果某個欄位，或一組欄位會出現在一個會被頻繁呼叫的where子句中，那麼它們應該是被索引的，這樣會更快的得到結果。同時，唯一索引的用途前面提到了，恰當的使用它們，避免意外的發生。我個人不推薦使用全文索引，尤其對於漢字來說，全文索引的開銷太大了，我寧可選擇搜尋引擎提供的站內搜尋功能。雖然搜尋引擎的收錄不是很及時，但是我覺得也不是不能接受。

再說一次，我覺得應該儘量在插入/修改/刪除資料的時候多做一些事情，相對來說，這些操作不那麼頻繁，而且單次操作的資料量也更小。不要將壓力都留給查詢語句。

事務、觸發器與儲存過程

哦，事務處理其實是程式中要做的事情，多條資料操作語句應該放入事務處理中，我們需要隨時注意保證資料的完整。

觸發器和儲存過程可以減少程式中的sql語句數量，同時減少了程式與資料庫之間通訊帶來的損耗。

特別是觸發器，它能極大的幫助我們，本站的資料庫設計中就使用了它，例如你發表回覆或刪除回覆的時候會觸發一個更新文件回覆數量的操作。不過由於MySQL資料庫中級聯操作無法使觸發器觸發的怪癖可能需要你做更多的處理才能讓觸發器順利工作。

結語

請認真而仔細的設計你的資料庫，並且使表名稱和欄位名稱都易於理解並避免混淆。例如，代表刪除狀態的欄位最好命名為trashed表示已刪除，而不是trash，明顯的，當你看到值為1的時候前者你能明白這表示已經刪除了，而對於後者你恐怕就拿不準了。

你可以想象為資料庫結構是軟體的等比例模型，就像是售樓處的模型一樣，它只會比實物更漂亮而不是更醜。所以如果你的資料庫不夠美觀，你的軟體質量基本已經定性為不堪入目了。

如果你有什麼意見和想法可以點選這裡開啟原文地址並通過回覆的方式告訴我，只有註冊使用者才能回覆哦。呵呵。