我最近遇到了 Percona Server 对普通 MySQL InnoDB 实施的更改。新功能是innodb_fast_checksum
XtraDB 可以使用基于 4 字节字的更 CPU 效率的算法，这对某些工作负载可能是有益的（例如，可以执行大量 IO 的服务器上的写入繁重的工作负载）。
听起来不错，但我想知道是否有任何工作负载在这种更改中的性能会比旧方法差。
文档继续说：
在新算法之后检查原始算法，因此您可以拥有具有旧校验和的数据页和具有新校验和的数据页。但是在这种情况下，您可能会遇到从具有旧校验和的页面读取缓慢的情况。
因此，假设您innodb_fast_checksum按照建议启用并重建所有 InnoDB 表以删除旧校验和，是否存在对旧校验和进行额外检查会导致性能下降的情况？
总之，有什么理由不跑innodb_fast_checksum？
您粘贴的措辞非常具体：
这意味着它仍然可以读取旧的校验和，但是从现在开始，只有 Percona Server 才能读取您的数据。稍后在这里指出：
您必须将其放在上下文中——InnoDB 仅在从块存储设备读取页面时验证校验和，并在将其刷新回存储设备之前对其进行更新。在内存中时，不会维护校验和。
多年来，对磁盘的一次 IO 大约需要 5-10 毫秒（1 毫秒 = 1/1000 秒）。计算校验和可能需要大约 50 微秒（1 微秒 = 1/1000000 秒）。我没有 InnoDB 案例中的实际数据，但如果你用谷歌搜索“每个人都应该知道的数字”，你可能会同意我在一个数量级内是正确的。
现在进入一个我们拥有诸如 Fusion-io 闪存设备之类的时代，这些设备在纸面上有大约 20-30us 的访问时间，您可以看到重新评估校验和是有意义的。
我的一般建议：除非您确实需要，否则不要破坏与 MySQL 版本的向后兼容性。大多数人还不需要它。
摩根是对的。除非您运行的设备速度非常快且访问延迟非常低，否则 I/O 访问将使校验和时间相形见绌，而启用快速校验和只会产生微不足道的差异。