MyISAM：

第一，優化參數

這個表引擎只存儲索引的緩存，而不存儲數據的緩存。可以通過設置KEY_BUFFER_SIZE設置緩存大小，通過KEY_BUFER_BLOCK_SIZE設置cache block的size。

KEY_CACHE_DIVISION_LIMIT是設置LRU鏈表中hot area和warm area的分界值，為1-100之間。系統默認為100，也就是只有warm chain。KEY_CACHE_DIVISION_LIMIT告訴mysql該如何將整個cachechain劃分為hot area和warm area。

KEY_CACHE_AGE_GHRESHOLD，控制cacheblock從hotarea降級到warmarea的限制，系統默認為300，最小設置為100.值越小，被降級的可能性越大。

多key cache的使用

msyql4.1.1開始，myisam支持多個key cache。可以根據不同的需求，設置多個keycache 了。如，將使用非常頻繁但是更新操作很少的數據放入一個keycaceh中以防止在公共keycache中被清除出去。那些使用不是很頻繁而且經常會更新的數據放在另外一個keycache中。

mysql官方建議在比較繁忙的系統上使用三個keycache【key cache就是索引緩存】:

一個hotcache：使用20%的大小，用來存放使用非常頻繁而且更新少的表索引

一個coldcache：使用20%的大小，用來存放更新很頻繁的表索引

一個warmcache：使用剩下的60%空間，作為整個系統的默認keycache。

第二，預加載

在一個新系統剛上線的時候，系統會因為cache中沒有任何數據而出現短時間的負載過高。可以使用預加載機制將指定表的所有索引都加載到內存中。

第三，null值對統計信息的影響

myisam索引中會記錄值為null的列信息，只不過null值的索引鍵占用的空間非常少。所以，null會影響到mysql查詢優化器對執行計劃的選擇。于是，mysql提供了MYISAM_STATS_METHOD參數讓我們自行決定對索引中的null值的處理方式。如果MYISAM_STATS_METHOD=nulls_unequal，那么myisam在搜集統計信息的時候會認為每個null都是不同的，則給予該字段的索引就會更大，也就是說，myisam會認為distinct的值會更多。MYISAM_STATS_METHOD=nulls_equal則相反。

第四，并發優化

1、打開concurrent_insert，如果concurrent_insert為1，則當表中沒有刪除記錄留下的空余空間時候可以在尾部進行并行插入。concurrent_insert為2的時候，不管有沒有因為刪除而留下的空間，都會在尾部進行并行插入。

2、控制寫入操作的大小以防止過長的時間擁塞。

3、通過犧牲讀取性能來提高寫入性能。將寫入的優先級提高。

第五，其他優化

通過optimize命令整理myisam表的文件，是文件占用的空間連續。一般來說，每次做了較大的數據刪除操作之后，都要做此命令。

Innodb：

innodb和myisam最大區別有四點：

1、緩存機制

2、事務支持

3、鎖定實現

4、數據存儲方式

整體性能上的差異innodb和myisam會因為不同場景而表現出很大差異，正是因為這四點。

第一、innodb緩存優化

innodb和myisam的最大區別就是innodb不僅僅緩存了索引，同時還緩存實際的數據。所以，完全相同的數據庫，innodb可以使用更多的內存來緩存數據庫相關信息。前提是有足夠的內存。

innodb_buffer_pool_size設置了InnoDB存儲引擎需求最大的一塊內存區域的大小，直接關系到InnoDB存儲引擎的性能，所以如果我們有足夠的內存，盡可將該參數設置到足夠大，將盡可能多的InnoDB的索引及數據都放入到該緩存區域中，直至全部。

我們可以通過(Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100%計算緩存命中率，并根據命中率來調整innodb_buffer_pool_size參數大小進行優化。

innodb_log_buffer_size (global)　　這是InnoDB存儲引擎的事務日志所使用的緩沖區。在mysql寫入負載很高的情況下，可以增大這個參數來提高IO性能。

第二、事務優化

innodb支持的事務隔離級別如下：

1、read uncommited：常被稱為臟讀

2、read commited：在這一隔離級別下，不會出現dirty read。但是可能會出現non-repeatable read或者phantom read。

3、repeatable read：innodb的默認事務隔離級別。不會出現dirty read。也不會出現non-repeatable read，但是可能會出現phantom read。

4、serializable：serializable是標準事務隔離級別中的最高級。在事務中的任何時候看到的數據都是事務啟動時候的狀態。不論這期間是不是有其他事務已經修改了某些數據并提交。所以，在serializable下，phantom reads也不會出現。

innodb在修改數據的時候，只是修改buffer pool中的數據。并不是在一個事物提交之后就將buffepool中的數據同步到磁盤上。這里要理解連續讀寫和隨機讀寫。寫入磁盤的 過程是需要磁頭尋址的。連續讀寫是指將要寫入的東西寫入到一個連續地址空間。innodb不是每一次都將數據同步到磁盤，就是為了攢多數據之后，進行連續讀寫來減少磁盤IO。

系統崩潰之后，innodb是如何利用事務日志進行數據恢復的呢？

假設在某一時間，mysql crash了，那么，所有的bufferpool的數據都會丟失。包括已經修改了但是沒來得及刷新到磁盤上的數據。在mysql從crash之后再次啟動，innodb會通過比較事務日志中的所有記錄的checkpoint的信息和各個數據文件中的checkpoint信息，找到最后一次checkpoint所對應的log sequence number。然后通過事務日志中的變更記錄，將從崩潰之前最后一次checkpoint往后的所有變更重新應用一次。同步所有的數據文件到一致狀態。當然，對于logbuffer中未來得及同步到日志文件的變更數據，就再也無法找回了?？偟膩碚f，事務日志文件設置的越大，系認io性能越好，但是遇到crash，那么恢復的時間也越長。

innodb_flush_log_at_trx_commit默認設置為1，表示每次失誤的結束都會觸發log thread將logbuffer中的數據寫入文件，并通知文件系統同步文件。這個設置是安全的，能夠保證不論是mysql crash，還是os崩潰，還是主機斷電，都不會丟失任何已經提交的數據。

第三、數據存儲優化

innodb的聚簇主鍵已經了解了。但是聚簇主鍵也是有不好的地方的，不然其他數據庫廠商也大力推廣了。聚簇的最大問題就是索引鍵被更新造成的成本，并不只是索引數據可能會移動，而是相關的所有記錄數據都要移動。所以，為了性能考慮，盡量不要更新innodb的主鍵值。

innodb中的數據，不論是表還是索引，或者是存儲引擎的各種數據結構，都以page作為最小物理單位來存儲。每個page大小默認16K。extent由多個連續的page組成的一個物理存儲單位。一般來說每個extent64個page。每個segment有一個或者多個extent組成。每個segment都存放同一種數據。一般來說，每個表都會存放在一個單獨的segment中。

page>extent>segment>tablespace，后面的每一個都是由前面的一個或者多個組成。tablespace是innodb的最大結構單位。

在主鍵上的優化建議，

1、為了減小secondary index的大小，主鍵字段所占用的存儲空間越小越好。最好是integer。當然這并不絕對。

2、盡可能不要做主鍵的更新。

3、盡可能根據主鍵進行查詢操作。

第四、其他優化

autocommit相信都了解，根據自己的實際情況設置autocommit。

總結

以上是生活随笔為你收集整理的mysql 引擎是表级别_Mysql表引擎优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。