粗聊Mysql——你會建庫建表嗎？

　　本文中說到的“建”，並非單純的建一個庫，或是建一張表，而是你建好的庫和表在項目的運營中，是否能應付各種事件，下面我說說幾個我在項目中遇到的問題以及處理的方法，算是一個小小的心得，給大家分享下。

　　一、兩表之間若有關聯，你是否還在用主鍵進行關聯？

　　比如現在有2張表，一張新聞欄目表，一張新聞表，現在兩張表需要進行關聯，我想大多數人的做法肯定是在新聞表裡建一個新聞欄目id，然後把新聞欄目表裡的主鍵ID（自增）寫到這個欄位裡，通過這樣進行兩表關聯。

　　如果你是這樣做的，趕緊改掉這個習慣吧。也許你會問為什麼，欄目id是主鍵啊，又是自增的，為什麼這樣操作不行？原因其實很簡單，欄目我們會增加，也會刪除，刪除就會造成主鍵id之間會有斷號的情況，由於主鍵設定為自增，也就是說你之前刪掉的欄目，再進行添加，id是不會去補上哪個空缺的，而是一直遞增。這樣就會造成一種情況，如果那天對資料庫進行最佳化，把主鍵進行了重新排序（暫時沒有找到mysql最佳化軟體會最佳化主鍵，但是可以通過代碼刪除主鍵，然後從建立立自增主鍵來實現主鍵重新排序），那就徹底杯具了，欄目和文章完全對不上號了。所以我建議兩表之間關聯不用主鍵，而是單獨建一個編號的欄位，我們這裡可以用mysql的uuid()函數做為編號，相關文獻可以參考《UUID做主鍵好還是不好》，只所以一張表要2個主鍵，一個物理主鍵（自增id），一個邏輯主鍵（UUID），原因是：對於InnoDB這種聚集主鍵類型的引擎來說，資料會按照主鍵進行排序，由於UUID的無序性，InnoDB會產生巨大的IO壓力，此時不適合使用UUID做物理主鍵，可以把它作為邏輯主鍵，物理主鍵依然使用自增ID。至於效能，我本地測了下基本上沒差異，網上也有人做了10W條資料的測試——《實測MYSQL UUID效能》。

　　二、統一把主鍵類型設為bigint吧

　　bigint是從-2^63 (-9223372036854775808)到2^63-1 (9223372036854775807)的所有整型資料，儲存大小為8個位元組。而int是從-2^31 (-2,147,483,648)到2^31-1 (2,147,483,647)的整型資料，儲存大小為4個位元組。儲存空間擴大一倍，而儲存資料卻擴大N倍，再加上主鍵是一個自增的欄位，我們根本無法控制它會自增到多少數值，所以我通常在建表的時候，主鍵類型都是設為bigint的，同樣，上面提到的編號欄位類型也是bigint。

　　三、不要把varchar長度設太“死”

　　這也是我之前經常犯得一個毛病，比如手機，我就設定為varchar(11)，郵編設定成varchar(6)，姓名設定成varchar(10)等等等等，看似每個欄位都設定得很嚴謹，但是在項目實際進行中，這完全就是自找苦吃，比如手機，使用者偏偏就要在手機號前輸個0，又比如郵編，如果使用者輸入的是全形的數字呢？姓名就更不用說了，萬一是個少數民族的人，名字七八個字。所以我建議，既然定義為varchar，就代表不會涉及到計算，何不乾脆定義一個通用的長度，比如varchar(50)，如果真要限制長度，用程式去判斷，不要讓資料庫來限制，不然使用者輸了一長串，結果mysql就存了前幾個字元，讓人覺得這程式有問題。

　　還有就是，如果你是做cms這種通用後台，更別把欄位限制得太“死”，因為你無法預料之後的每個項目的需求，所以還是把varchar設大一點，我現在是統一都設為255，如果很有可能會超過255的欄位，比如URL，我就乾脆設定成text，一勞永逸。

　　四、為常用的搜尋欄位建立索引吧

　　不解釋，但不要盲目建立索引。

　　五、歡迎您的回複補充