有什麼理由不使用 Percona ‘innodb_fast_checksum’ 嗎？
我最近遇到了 Percona Server 在普通 MySQL InnoDB 上實現的更改。新功能是
innodb_fast_checksumXtraDB 可以使用基於 4 字節字的 CPU 效率更高的算法，這對於某些工作負載（例如可以執行大量 IO 的伺服器上的寫入繁重的工作負載）可能是有益的。
聽起來不錯，但我想知道是否存在任何工作負載，在這些工作負載中，這種更改的性能會比舊方法差。
文件接著說：
在新算法之後檢查原始算法，因此您可以擁有具有舊校驗和的數據頁和具有新校驗和的數據頁。但是，在這種情況下，您可能會遇到從具有舊校驗和的頁面中讀取速度緩慢的情況。
因此，假設您
innodb_fast_checksum按照建議啟用和重建所有 InnoDB 表以刪除舊校驗和，是否存在對舊校驗和進行額外檢查會導致性能下降的任何情況？簡而言之，有什麼理由不跑
innodb_fast_checksum嗎？
您粘貼的措辭非常具體：
在新算法之後檢查原始算法，因此您可以擁有具有舊校驗和的數據頁和具有新校驗和的數據頁。但是，在這種情況下，您可能會遇到從具有舊校驗和的頁面中讀取速度緩慢的情況。
這意味著它仍然可以讀取舊的校驗和，但是從現在開始，只有 Percona Server 將能夠讀取您的數據。稍後在此處註明：
一旦啟用，關閉它也需要重新創建表，因為它無法在啟用 innodb_fast_checksums 時創建的數據文件上啟動。
您必須將其放在上下文中 - InnoDB 僅在從塊儲存設備讀取頁面時驗證校驗和，並在將其刷新回儲存設備之前對其進行更新。在記憶體中時，不維護校驗和。
多年來，磁碟的 IO 花費了大約 5-10 毫秒（1 毫秒 = 1/1000 秒）。計算校驗和可能需要大約 50 微秒（1 微秒 = 1/1000000 秒）。我沒有 InnoDB 案例中的實際數據，但如果你Google“每個人都應該知道的數字”，你會希望我在一個數量級內是正確的。
現在進入一個我們擁有諸如 Fusion-io 快閃記憶體設備之類的東西的時代，這些設備在紙面上的訪問時間約為 20-30 微秒，您可以看到重新評估校驗和是有意義的。
**我的一般建議：**除非你真的需要它，否則不要破壞你與 MySQL 版本的向後兼容性。大多數人還不需要它。