MySQL的主鍵和欄位型別問題總結

主鍵問題：
Innodb的索引檔案本身就是資料檔案，即B+Tree的資料域儲存的就是實際的資料，這種索引就是聚集索引。這個索引的key就是資料表的主鍵，因此InnoDB表資料檔案本身就是主索引。
InnoDB的輔助索引資料域儲存的也是相應記錄主鍵的值而不是地址，所以當以輔助索引查詢時，會先根據輔助索引找到主鍵，再根據主鍵索引找到實際的資料。所以Innodb不建議使用過長的主鍵，否則會使輔助索引變得過大。建議使用自增的欄位作為主鍵，這樣B+Tree的每一個結點都會被順序的填滿，而不會頻繁的分裂調整，會有效的提升插入資料的效率。

欄位型別問題：
mysql是基於行的資料庫，而資料讀取則是基於page的。每個page中存放有行。如果每一行的資料量都減小，那麼每個page裡面存放的行就增多了。每次io就能偶取出更多的行。
數字型別：萬不得已，不要用double型別。除了佔用空間比較大之外，還有精度問題。同樣，固定精度的小數也不要使用decimal，建議乘以固定倍數，轉換成整數進行儲存。可以節省儲存空間，而且不用任何附加維護成本。對於整數的儲存，建議分開tinyint/int/bigint，他們儲存資料佔用空間有一定差距。
字元型別：首選char型別，其次varchar，萬不得已，不要用text型別。它的處理效率低於char和varchar。varchar切不可以隨意給一個很大的長度。
時間型別：儘量使用timestamp。儲存空間佔用只是datetime型別的一半。對於需要精確到某一天的型別，建議使用date型別。因為它儲存需要三個位元組。比timestamp還少。不建議使用int來儲存一個unix timestamp，不直觀，不會帶來任何好處。