http://www.penglixun.com/tech/database/percona_vs_mysql.html
週末有空讀了下Percona XtraDB對MySQL InnoDB的改進點，這裏給大家分享下。
一、對可擴展性的改進：
1. 提升Buffer Pool的擴展性
InnoDB Buffer Pool一個衆所周知的問題是大併發查詢執行的爭用，XtraDB將Buffer Pool的全局Mutex拆成了多個Mutex以減少爭用。
2. 提高InnoDB IO擴展性
XtraDB增加了許多變量去調整IO到最佳狀態，包括調整checkpoint、後臺讀寫數據文件線程數等等的參數。
3. 多個回滾段
爲提供一直讀，InnoDB將事務修改的數據寫到回滾段。回滾段被一個獨立的Mutex保護，這直接導致了寫密集型的工作併發不高。在 XtraDB可以改變回滾段的數目（innodb_extra_rsegments），在寫密集型操作中可以大幅度提高性能。
4. 可以更高的併發數
InnoDB在回滾段只提供了1024個回滾槽（春哥就遇到過這個瓶頸），如果回滾槽用完，新的事務將不能開始，直到有回滾槽被釋放。
二、性能上的提升
1. 專用的Purge線程
在InnoDB一個事務修改的數據被寫到共享表空間的undo space，所以InnoDB能提供讀一致。到一個事務結束了，undo
space的相應區域被釋放。但是如果有很多事務，Purge線程清理空間不夠快，共享表空間將急劇增長（BRMMS共享表空間巨大應該是這個原因）。這
將導致性能嚴重下降，甚至可能用完所有的磁盤空間。XtraDB使用了一個專用的線程來清理undo space，這對undo
space的清理速度可以提升很多。儘管這可能使整體的性能降低，但是可以大大提高穩定性，因而整體性能略微降低是值得的。
2. 可配置的Doublewrite緩衝
InnoDB使用了double write功能來防止數據損壞，double
write的意思是，是寫數據到文件前，先順序寫到到共享表空間。如果遇到一個損壞的寫，InnoDB將使用這個buffer去恢復數據。儘管數據被寫了
兩次但對性能影響通常較小，但是在一些高負載環境，doublewrite就成了瓶頸。XtraDB提供了一個選項將doublewrite
buffer放在一個獨立的磁盤來提升併發性能。
3. Query Cache增強
Percona提供了額外的參數來配置Query Cache，例如忽略SQL
中的註釋性語句來檢查是否可以命中。
4. Fast InnoDB Checksum
InnoDB可以checksum所有從磁盤上讀取的頁，以提供防止數據損壞的額外安全保障。在XtraDB中，Percona改進算了 checksum算法，可以提供更好的性能。
5. 刪除過多的函數調用
當MySQL從socket讀數據時，將產生很多fcntl（針對描述符提供控制的函數）調用，導致併發性能下降。Percona移出了多於 的調用。
6. 減少了Buffer Pool Mutex競爭
在InnoDB內核操作時減少了Buffer Pool之間的Mutex爭用（拆分Mutex變量）
三、靈活性改進
1. 支持多種頁大小
儘管InnoDB支持多種頁大小，但是默認的頁大小16K無法在不重新編譯的情況下改變。XtraDB提供一個系統變量 （innodb_page_size）來改變這個值。更小的頁大小可以提升大多數OLTP系統的工作性能，更大的頁通常可以提供更好的 OLAP性能。
2. 禁止Replication警告
默認的基於Statement的複製，例如NOW(),RAND()，call存儲過程/函數等一些語句，或者UPDATE沒有ORDER
BY而使用LIMIT，可能是不安全的。在這種情況下，MySQL會發出1592警告（聲明語句在Statement日誌下是不安全的）。不
幸的是，MySQL 5.1的一個Bug導致Server發出這個警告在一些安全的情況下。索然他不會導致任何與複製相關的問題，但是這會導致Error
Log裏面存在沒必要的報警。這個改進可以避免這些警告。
3. 處理BLOB中的行結束符
Percona(5.1.x-12.x開始，5.1.x-11.x不支持)爲MySQL客戶端提供一個新的選項（no-remove- eol-carret）來處理Blob字段含/r字符的情況。
4. 複製停止恢復
當使用sql_slave_skip_counter參數時，如果一個事件組的中間某條出錯了，slave將跳過所有剩餘的時間操作直到這個 事件組結束。表述比較困難，直接看Percona給的使用例子就明白了。
http://www.percona.com/docs/wiki/percona-server:features:replication_skip_single_statement
5. 可固定的預讀區
在InnoDB中，預讀（read-ahead區域）的大小是動態計算的，但是它經常是一個同樣的值。XtraDB(5.1.x-12.x開 始，5.1.x-11.x不支持)可以讓這個這個區域的大小固定，避免無用的計算。
這是Facebook放出的補丁：http://bazaar.launchpad.net/~mysqlatfacebook/mysqlatfacebook/5.1/revision/3538
四、可靠性的改進
1. Crash後同步日誌
在InnoDB中，slave複製狀態存儲在兩個不同步的文件中(relay.index和relay.info)。如果slave因爲錯誤
狀態而停止，文件將不同步，最後的事務將重新執行。Percona在XtraDB事務日誌中增加了複製狀態：當重啓事務時，slave可以使
用這個信息來實現一致性。
來自Google的補丁：http://code.google.com/p/google-mysql-tools/wiki/TransactionalReplication
這個缺陷可能導致的Bug：http://bugs.mysql.com/bug.php?id=34058
2. Too Many Connections的警告
Percona將“Too Many Connections”這個警告寫入Server端的error_log，而不只是客戶端報這個錯。
3. 錯誤代碼的兼容性
Percona(5.1.x-12.x開始，5.1.x-11.x不支持)提供與MySQL 5.5錯誤代碼的兼容性，避免因爲升級到5.5而帶來錯誤碼不一樣的問題。
4. 文件句柄損壞的表（InnoDB）
MySQL在InnoDB有表損壞之後，所有的InnoDB表都不可用。XtraDB改進了這一點，只是disable損壞的表，數據庫依然 可以使用其他的表，損壞的表被鎖定。
五、可管理性的提升
1. Fast InnoDB Recovery
InnoDB一直以來有個很麻煩的事情，在crash後回覆InnoDB的表非常的緩慢。Percona/XtraDB因爲是基於 InnoDB
Plugin 1.0.8+的，也具備InnoDB
Plugin快速恢復的功能。（早期的Percona版本也能看到XtraDB恢復速度比InnoDB快很多，因爲XtraDB早期使用了自己開發的
Fast Revcovery）
一些測試：http://www.mysqlperformanceblog.com/2009/07/07/improving-innodb-recovery-time/
2. InnoDB 數據字段大小限制
InnoDB在自己的表緩存（Table Cache）中分配存儲表定義（Table
Definitions）的內存稱爲數據字典。默認情況下，一旦打開表，字典中表示它的內部對象將一直保存在內存中，直到表被刪除或者服務器重啓。如果存
在很多表（例如
10萬張或更多，Dubbo就有這種情況，logstat庫），可能導致消耗巨大的內存有時可能達到G級別。Percona修改了這種策略，可以設置參數
（innodb_dict_size_limit）來限制數據字典的大小，使InnoDB使用LRU算法來限制數據字典大小，而不是一直存在
內存中，避免因爲表太多而內存耗盡。
3. 展開表導入
InnoDB不像MyISAM那樣可以在服務器之間拷貝單表定義文件。如果配合Xtrabackup導出，一張表可以在另一個XtraDB導 入。
4. Buffer Pool使用共享內存
當Buffer Pool非常大時，重啓後Warn up需要大量磁盤讀寫，這會消耗很多時間。通過將Buffer Pool存儲在Shared Memory中，這些非是耗時的IO將會節省掉。主機重啓就沒辦法了，得用下面的功能。
5. 導出/恢復Buffer Pool
對於使用了很大Buffer Pool的InnoDB，重啓數據庫很痛苦。通常需要InnoDB Buffer Pool先Warn
Up再提供服務，這可能需要很久。XtraDB(5.1.x-12.x開始，5.1.x-11.x不支持)提供了命令可以把Buffer
Pool的內容導入或導出，從而可以提高重啓提供服務的速度。
使用方法：http://www.percona.com/docs/wiki/percona-server:features:innodb_lru_dump_restore?redirect=1
6. Fast Index Creation
快速索引創建是InnoDB
Plugin的功能，只要不是主鍵變動，修改索引的速度比之前快很多。但是在一些場景下，這可能導致損壞。XtraDB提供參數
（innodb_fast_index_creation）來選擇Fast Index
Creation功能是否啓用，如果關閉，則使用原來的創建方法。
7. Fast Index Renaming
XtraDB（(5.1.x-12.x開始，5.1.x-11.x不支持)）擴展了ALTER TABLE命令，提供在線重命名索引功能，這樣不會導致重建索引。（這對我們調整不規範索引名稱非常有用）
8. 防止緩存Flashcache
Flashcache通過在SSD上緩存數據來提升性能。它工作時應該讓更熱的數據緩存才能能提高更好的性能，XtraDB提供了註釋提示來 忽略不必緩存的數據。
六、診斷問題方面的提升
1. 額外的INFORMATION_SCHEMA表
Percona/XtraDB提供額外的INFORMATION_SCHEMA表以獲得數據庫內部更詳盡的信息，例如內部緩衝池的內容或統計 信息。
2. 慢查日誌擴展
Percona提供了額外的統計數據，可以通過參數啓用。它可以幫助我們捕捉需要的事件儘可能詳細的信息，簡化了慢查分析的難度。
3. InnoDB狀態顯示
XtraDB整理了InnoDB Status的顯示量，提供更好的可讀性，狀態由24個上升到48個，並且打印了被內部哈希表使用的內存量。通過新的參數可以配置的輸出。
4. 計算InnoDB死鎖數
當運行一餓事務性的應用程序，總會不同程度的出現死鎖，只要不經常出現這並不是大的問題。InnoDB中Show InnoDB
Status命令只給出了最後一次死鎖額信息，當我們需要知道總的死鎖數或一個單位時間的死鎖量這裏並不能給出。XtraDB增加了一個保存死鎖量的狀態
變量，通過這個變量可以更好的瞭解我們數據庫上發生的死鎖。
5. 可以記錄所有Server端命令（syslog）
Percona可以在syslog中記錄所有運行在Server端的命令。
6. 響應時間分佈
Percona提供了一份報告表明在一定間隔內在服務器上執行Query數。這個信息可以用於監控數據庫性能是否穩定。
7. Show Storage Engines
Percona改變了Show Storage Egnines的輸出，以表名XtraDB是不是啓用。（以前XtraDB也使用InnoDB的名稱輸出）
8. Query Cache Mutex狀態
Query Cache可能導致一些很難被檢測出來的問題，Percona修改了show processlist命令，可以輸出“Waiting on query cache mutex”狀態。
9. 顯示鎖名稱
“show mutex status”命令可以顯示當前發生的鎖定名稱和os_wait值。