本文中說到的「建」，並非單純的建乙個庫，或是建一張表，而是你建好的庫和表在專案的運營中，是否能應付各種事件，下面我說說幾個我在專案中遇到的問題以及處理的方法，算是乙個小小的心得，給大家分享下。
一、兩表之間若有關聯，你是否還在用主鍵進行關聯？
比如現在有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，一勞永逸。
四、為常用的搜尋字段建立索引吧
不解釋，但不要盲目建立索引。
五、歡迎您的回覆補充
mysql建立使用者表 mysql 建庫建表建使用者
1.建立資料庫 create database school 2.使用資料庫 use school 3.建立使用者 create user jame localhost identified by jame 4.授權使用者 注意這裡是用了 哦，可以自己講school也替換成 號 grant sele...
mysql登入，建庫，建表
cmd下 mysql u使用者名稱 p密碼 使用者名稱可以用root 密碼沒有可以不設 顯示資料庫 show databases 檢視當前使用的資料庫 select database 建立資料庫 create database 資料庫名 character set utf8 字符集 collate ...
MySQL簡單建庫建表操作
create database selecttest character set utf8 use selecttest 1.學生表 student create table student sno varchar 20 primary key,sname varchar 20 not null,s...