一、資料型別的優化

（1）MySQL資料型別

• 整數型別：
  
  • TinyInt，儲存空間8， 位元組長度1；
  • SmallInt， 儲存空間16， 位元組長度2；
  • MediumInt，儲存空間24， 位元組長度3；
  • Int，儲存空間32， 位元組長度4；
  • BigInt，儲存空間64， 位元組長度8；
• 實數型別：
  
  • Float：位元組長度8，單精度浮點數；
  • Double：位元組長度16，雙精度浮點數；
  • Decimal：未打包的浮點數，計算中會轉化為Double；Decimal 相比於 Float 和 Double 需要額外的空間和計算開銷，因此儘量只在對小數進行精確計算時才使用，例如儲存財務資料。在資料量比較大的時候，可以考慮使用 BigInt 代替 Decimal，將需要儲存的貨幣單位根據小數的位數乘以相應的倍數即可。 　
• 字串型別：
  
  • VarChar：儲存可變長字串，需要一個或兩個額外位元組記錄字串長度。適用於：字串列的最大長度比平均長度大很多；列的更新很少（所以碎片不是問題）；使用了UTF-8這樣複雜的字符集，每個字元都使用不同的位元組數進行儲存。
  • Char：定長，根據定義的字串長度分配足夠的空間。Char 適合儲存很短的字串，或者所有值都接近同一個長度。如：儲存密碼的MD5值（這是一個定長的值）；經常變更的資料（定長的 Char 型別不容易產生碎片）；非常短的列，比如用 char(1) 來儲存只有Y和N的值，如果採用單位元組字符集只需要一個位元組，但是 varchar(1) 卻需要兩個位元組（還有一個記錄長度的額外位元組）。
• 時間型別
  
  • DATETIME：使用8位元組儲存空間，將日期和時間裝到格式為YYYYMMDDHHMMSS的整數中；
  • TIMESTAMP：使用4位元組儲存空間，顯示的值依賴於時區。儘量使用它，因為它的空間效率更好。

（2）優化策略

• 更小的通常更好
  
  • 更小的通常更快，因為它佔用更小的磁碟、記憶體和cpu快取，且處理時需要的cpu週期更小；
  • 但是要確保沒有低估需要儲存的值的範圍。
• 簡單就好
  
  • 簡單的資料型別操作需要更少的cpu處理週期；
  • 如：整型比字串代價更低、MySQL內建型別（date，time，datetime）而非字串來儲存時間、用整型儲存IP地址。
• 儘量避免使用NULL
  
  • 通常最好指定列為NOT NULL，除非真的需要儲存NULL值；
  • 因為如果查詢中包含可為 NULL 的列，對 MySQL 來說更難優化，因為可為 NULL 的列使得索引、索引統計和值比較都更復雜；可為 NULL 的列會使用更多的儲存空間，在MySQL裡也需要特殊處理；當可為 NULL 的列被索引時，每個索引記錄需要一個額外的位元組。

二、索引優化

（1）索引型別

• B-Tree索引：
  
  • 通常意味著所有值按順序儲存，並且每一個葉子葉到根的距離相等；
  • 能加快訪問速度，因為儲存引擎不需要全表掃描來捕獲需要的資料，而是從索引的根節點開始進行搜尋；
  • 對索引順序儲存，所以很適合查詢範圍資料
• B-Tree索引有效的查詢型別：
  
  • 全值匹配：和索引中所有列進行匹配；
  • 匹配最左字首：只使用索引第n列匹配；
  • 匹配列字首：只匹配某一列值的開頭部分；
  • 匹配範圍值：某一列在xx和xxx之間的值；
  • 精確匹配某一列，範圍匹配另一列：某一列全匹配，另一列範圍匹配；
  • 只訪問索引的查詢：只訪問索引，不訪問資料行。
• B-Tree索引的限制：
  
  • 如果不是按照索引的最左列查詢，則無法使用索引；
  • 不能跳過索引中間的列；
  • 如果查詢中有某個列的範圍查詢，則其右邊所有列都無法使用索引優化查詢；（如果範圍查詢有限，建議使用多個等於代替範圍查詢）。
• 雜湊索引：
  
  • 基於雜湊表實現，只有精確匹配索引所有列的查詢才有效；
  • 對於每一行資料，儲存引擎都會對所有索引列計算一個雜湊碼，雜湊索引將所有雜湊碼儲存在索引中，同時在雜湊表中儲存指向每個資料行的指標；
• 雜湊索引的限制：
  
  • 只包含雜湊值和行指標，不儲存欄位，所以不能使用索引中的值避免讀取行；
  • 不是按索引值順序儲存，所以不能排序；
  • 不支援部分索引列匹配查詢；
  • 訪問雜湊索引的速度非常快，除非出現很多雜湊衝突，出現很多雜湊衝突的話，一些索引維護的代價非常大；
• 雜湊索引的應用：
  
  • InnoDB“自適應雜湊索引”：某些索引值被引用的非常頻繁，他會在記憶體中基於B-Tree索引的基礎上建立一個雜湊索引。

（2）高效能索引策略：

• 索引的優點：
  
  • 索引可以大大減少資料庫表的掃描量
  • 索引可以幫助伺服器避免排序和臨時表
  • 索引可以將隨機I/O變成順序I/O

• 索引選擇：

  • 字首索引：使得索引更小，更快（比如要索引很長的字串），但是無法做GROUP BY和ORDER BY操作，也無法覆蓋掃描；
  • 索引列順序：經驗法則是將選擇性最高的放在最前面；

• 聚簇索引：實際上是一種資料的儲存方式

  • 資料航存放在索引的葉子結點，且資料行和相鄰的鍵值緊湊地存放在一起
  • 優點：
    
    • 可以將相關資料儲存在一起，減少磁碟I/O
    • 索引和資料儲存在一個B-Tree，資料訪問更快
    • 使用覆蓋索引的掃描時可以直接使用主鍵
  • 缺點：
    
    • 插入速度依賴於插入順序，最好是按照主鍵順序插入
    • 更新列代價很高
    • 插入行可能導致頁分裂

三、查詢優化

（1）優化資料訪問

• 避免查詢不需要的記錄：使用limit；
• 避免多表查詢查詢所有列：不要隨意使用select * ；
• 重複查詢相同資料：採用快取；

（2）從好到壞的where條件應用

• 最佳：儲存引擎層在索引中使用where過濾不匹配的記錄
• 次佳：使用索引覆蓋掃描，直接從索引中過濾不需要的記錄並返回，在伺服器層完成
• 最次：先從資料表中返回資料，然後過濾，需要回表查詢

（3）重構查詢

• 一個複雜查詢改為多個簡單查詢
• 切分查詢：
  
  • 對大查詢“分而治之”，減少鎖持有的時間
  • 例如刪除過期記錄，每次LIMIT 10000，否則可能一次鎖住很多資料，佔滿整個事務日誌，耗盡系統資源，阻塞很多小但是重要的查詢；
• 分解關聯查詢：
  
  • 讓快取效率更高；
  • 減少鎖的競爭；
  • 應用層關聯便於表的拆分，更容易做到高效能和可擴充套件；
  • 減少冗餘記錄查詢；

參考文獻：《高效能MySQL》