以下觀點參考《高效能 mysql》,歡迎指教。
1 更小通常更好
選擇表示資料的最小型別（正確儲存你的內容）：比如說，能夠使用char 資料型別儲存，就不必選擇text,能夠使用int型儲存資料，就不應該使用long型。
理由：更小的資料型別使用了更小的磁碟空間，記憶體和cpu快取，而且需要的cpu週期也更少。
ps：確保不會低估要儲存的值。（能夠很好的把握需求，對要儲存的資料要比較精確的判斷）
2 簡單就好
這個好理解，盡可能選擇簡單的資料型別儲存資料，mysql的資料型別不外乎int,long,char，varchar,text等等。那麼在選擇的時候，盡量選擇最簡單的基本資料 型別儲存資料。比如我平常儲存時間的時候一般都是存成int型別**化成timestamp）.
理由：越簡單的資料型別，需要的cpu週期越少。
3 盡量避免null
盡可能的把字段定義為 not null
理由:mysql 難以優化引用了可空列的查詢，空列會使索引，索引統計和值更加複雜，可空列需要更多的儲存空間。一般來說，設定預設值（default)是個比較好 的習慣。當然該條對mysql表效能的提公升影響不是很大，不應放在最優先考慮的地位。
綜上所述，我們在設計乙個mysql資料表的時候：
第一步：大致確定欄位的資料型別，數字，字串，時間等，比較直觀
第二步：確定特定的型別，比如說 ：數字裡有tinyint,smallint,int,long等，選擇最合適的乙個（更小通常更好）
第三步：如有必要，請為字段設定預設值。
當然，索引優化肯定是必不可少的，不過這屬於設計表完成之後的優化範圍了。
**：
Redis高效能資料庫
redis高效能資料庫 redis 本質上是乙個非關係型資料庫，採用鍵值的方式記錄資料，由於其獨特的執行模式和資料儲存模式，在作用上通常可以用來當做關係型資料庫的快取來使用，從而提高資料查詢效率 redis最大特點 執行速度很快 原因 1 redis使用c語言開發，和作業系統的相容性更強，執行效率更...
MySQL 資料庫表設計
字段具有原子性,不可再分。所有關係型資料庫系統都滿足第一正規化 資料庫表中的字段都是單一屬性的，不可再分 要求實體的屬性完全依賴於主鍵。所謂完全依賴是指不能存在僅依賴主鍵一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成乙個新的實體，新實體與原實體之間是一對多的關係。為實現區分...
高效能架構設計 資料庫篇
高效能資料庫集群的第一種方式是 讀寫分離 其本質是將訪問壓力分散到集群中的多個節點，但是沒有分散儲存壓力 第二種方式是 分庫分表 既可以分散訪問壓力，又可以分散儲存壓力。讀寫分離的基本實現是 解決主從複製延遲有幾種常見的方法 1.寫操作後的讀操作指定發給資料庫主伺服器 2.讀從機失敗後再讀一次主機 ...