存儲引擎 MyISAM InnoDB

 

InnoDB

數據存儲在表空間中(tablespace)

採用MVCC支持高併發

默認級別repeatable read級別

採用間隙鎖來防止幻讀的現象出現

表是基於聚簇索引創建的，對主鍵查詢有很高的性能

Percona提供的XtraBackup能夠作到真正的熱備份

 

MyISAM會將表存儲在兩個文件中，數據和索引文件，分別以.MYD和.MYI爲擴展名

InnoDB索引和MyISAM索引的區別：

一是主索引的區別，InnoDB的數據文件自己就是索引文件。而MyISAM的索引和數據是分開的。

二是輔助索引的區別：InnoDB的輔助索引data域存儲相應記錄主鍵的值而不是地址。而MyISAM的輔助索引和主索引沒有多大區別。

 

uuid仍是自增bigint

須要看你索引適應的形式，若是使用 b-tree 索引形式，有序 id 比無需 id 好，若是是 hash 索引，兩個差異不大。主要緣由是索引在磁盤上存儲的形式，經常使用的 b-tree 索引若是 id 是連續的，那麼數據存儲在相鄰的磁盤上，若是查詢和寫入操做的 id 連續，那麼減小隨機讀寫硬盤的概率，提高讀寫效率。

innodb引擎下，數據記錄是保存在B+樹的葉子節點（大小至關於磁盤上的頁）上，當插入新的數據時，若是主鍵的值是有序的，它會把每一條記錄都存儲在上一條記錄的後面，可是若是主鍵使用的是無序的數值，例如UUID，這樣在插入數據時Innodb沒法簡單地把新的數據插入到最後，而是須要爲這條數據尋找合適的位置，這就額外增長了工做，這就是innodb引擎寫入性能要略差於MyISAM的緣由之一

 

 

MyISAM

• • 特性

• • 1. 不支持事務：MyISAM存儲引擎不支持事務，因此對事務有要求的業務場景不能使用
    2. 表級鎖定：其鎖定機制是表級索引，這雖然可讓鎖定的實現成本很小可是也同時大大下降了其併發性能
    3. 讀寫互相阻塞：不只會在寫入的時候阻塞讀取，MyISAM還會在讀取的時候阻塞寫入，但讀自己並不會阻塞另外的讀
    4. 只會緩存索引：MyISAM能夠經過key_buffer緩存以大大提升訪問性能減小磁盤IO，可是這個緩存區只會緩存索引，而不會緩存數據

• • 適用場景

• • 1. 不須要事務支持（不支持）
    2. 併發相對較低（鎖定機制問題）
    3. 數據修改相對較少（阻塞問題）
    4. 以讀爲主
    5. 數據一致性要求不是很是高

• • 最佳實踐

• • 1. 儘可能索引（緩存機制）
    2. 調整讀寫優先級，根據實際需求確保重要操做更優先
    3. 啓用延遲插入改善大批量寫入性能
    4. 儘可能順序操做讓insert數據都寫入到尾部，減小阻塞
    5. 分解大的操做，下降單個操做的阻塞時間
    6. 下降併發數，某些高併發場景經過應用來進行排隊機制
    7. 對於相對靜態的數據，充分利用Query Cache能夠極大的提升訪問效率
    8. MyISAM的Count只有在全表掃描的時候特別高效，帶有其餘條件的count都須要進行實際的數據訪問

InnoDB

• • 特性

• • 1. 具備較好的事務支持：支持4個事務隔離級別，支持多版本讀
    2. 行級鎖定：經過索引實現，全表掃描仍然會是表鎖，注意間隙鎖的影響
    3. 讀寫阻塞與事務隔離級別相關
    4. 具備很是高效的緩存特性：能緩存索引，也能緩存數據
    5. 整個表和主鍵以Cluster方式存儲，組成一顆平衡樹
    6. 全部Secondary Index都會保存主鍵信息

• • 適用場景

• • 1. 須要事務支持（具備較好的事務特性）
    2. 行級鎖定對高併發有很好的適應能力，但須要確保查詢是經過索引完成
    3. 數據更新較爲頻繁的場景
    4. 數據一致性要求較高
    5. 硬件設備內存較大，能夠利用InnoDB較好的緩存能力來提升內存利用率，儘量減小磁盤 IO

• • 最佳實踐

• • 1. 主鍵儘量小，避免給Secondary index帶來過大的空間負擔
    2. 避免全表掃描，由於會使用表鎖
    3. 儘量緩存全部的索引和數據，提升響應速度
    4. 在大批量小插入的時候，儘可能本身控制事務而不要使用autocommit自動提交
    5. 合理設置innodb_flush_log_at_trx_commit參數值，不要過分追求安全性
    6. 避免主鍵更新，由於這會帶來大量的數據移動