數據類型選擇方面的幾個原則：
1，更小通常更好，選擇能正確表示數據的最小類型。
2，簡單就好，用簡單類型優於用復雜類型。
3，避免NULL，盡量定義字段為not null。性能提升很小。
字符串的選型：
當最大長度遠遠大於平均長度時，並很少發生更新時，選擇VARCHAR。
CHAR適合保存用戶密碼的MD5哈希值。
MySql存儲的最小時間單位是秒，但是可以用毫秒進行臨時計算。
InnoDB有一個特別功能叫做自適應哈希索引，當InnoDB注意到一些索引值被很頻繁的訪問的時候，它就會在BTree的頂端為這些值建立內存索引。
索引包含了來自於表中的一列或者多列的值，如果索引了多列數據，列的順序非常重要，因為Mysql只能高效的搜索所以你的最左前綴。
聚集索引：不是一種單獨的索引類型，而是一種存儲數據的方式。當表有聚集索引的時候，它的數據行實際保存在索引的葉子頁中。每個表只能有一個聚集索引。
使用時注意設置前綴索引。索引選擇要注意不重復的索引值。
索引策略總結：
檢查最常用的查詢，不要不調查就隨便建索引。為了找到建索引的平衡，應該測試和剖析。第一檢查的就是響應時間，要為耗時很長的查詢添加索引；然後就是檢查導致最大負載的查詢，添加索引；最好要把系統的cpu、內存和磁盤瓶頸考慮進去。
在任何可能的地方，都要試著擴展索引，而不是新增索引。通常維護一個多列索引要比維護多個單列索引容易。如果不知道查詢的分布，就要盡可能的使索引變得更有選擇性，因為高選擇性的索引通常更有好處。
在冗余方面：
通常需要額外的索引、冗余的字段，或者甚至緩存表和匯總表來加速讀取。這為寫入查詢和維護工作增加了工作量，但這仍然是設計高性能查詢的常見技巧：用極大的加速讀取來彌補較慢的寫入的代價。（但是也為讀寫增加了開發復雜性）
InnoDB存儲引擎的一些tip：
“
事務性：支持事務和四種事務隔離級別。
外鍵：在Mysql 5.0中唯一的支持外鍵的存儲引擎。
行級鎖：鎖設定於行一級，不會向上傳遞並且也不會阻塞選擇——標准選擇根本不會設定任何鎖，有很好的並發特性。
多版本：InnoDB使用多版本並發控制，默認情況下不會選擇讀取陳舊數據。
按主鍵聚集：所有InnoDB表都是按主鍵聚集的。
所有索引包含主鍵列：索引按照主鍵引用行，因此，如果不把主鍵維持的很短，索引就會很大。
優化的緩存：InnoDB把數據和內存緩存在緩沖區池裡。會自動構建哈希索引來加快行讀取。
未壓縮的索引：索引沒有使用前綴壓縮，因此可能會比MyISAM表的索引大很多。
數據裝載緩慢：在MySql5.0中，InnoDB不會特別優化數據加載。它一次構建一行的索引，而不是按照排序進行構建。導致加載緩慢。
阻塞AUTO_INCREMENT：在MySql5.1之前的版本，InnoDB使用了表級鎖來產生每個新的auto_increment值。
沒有緩存的count(*)值：和MyISAM表或Memory表不同，InnoDB表不會把表的行數保存在表中，這意味著沒有where子句的count(*)查詢不會被優化掉，並且需要全表或索引掃描。
”
查詢優化：
在下面的應用場景中，在應用程序端進行聯接效率更高：可以緩存早期查詢的大量數據；使用了多個MyISAM表；數據分布在不同的服務器上；對於大表使用in()替換聯接；一個聯接引用了同一個表很多次。
查詢緩存：Mysql對查詢緩存的實現就是將查詢文本作為key，將結果集作為value的一個map。因此，查詢語句的任何一點變化都會導致緩存不命中，書寫一致的查詢語句就成了mysql操作的要點。另外就是查詢緩存不緩存任何包含不確定函數的查詢，比如NOW()。換句話說，用戶自定義的函數，變量等等都不會被緩存。（原理是這樣的，服務器會執行一次不區分大小寫的檢查來驗證查詢是否以SEL打頭）。另外值得說明的是，結果太大也不會被緩存的。建立緩存也是有開銷的，比如內存分配等，開啟了緩存後查詢就會檢查，這也是性能開銷，因此開啟與否要根據情況仔細斟酌
摘自 Change Dir
