应设为 crc32；它是 mysql 5.7+ 默认值，硬件支持好、开销低，能在读取时校验失败并主动报错，有效防止损坏页静默蔓延，兼顾安全性与性能。
innodb_checksum_algorithm 该设成什么值
InnoDB 默认启用校验和（checksum），用于在读取页时验证数据完整性。但不同版本 MySQL 的默认值不同，且错误配置可能让损坏页被静默跳过，反而掩盖问题。
MySQL 5.7+ 默认是 innodb_checksum_algorithm = crc32，它比旧的 innodb（即“traditional”）更快、更可靠；而 none 或 strict_crc32 都不推荐：前者彻底禁用校验，后者仅在写入时校验、读取时不校验，失去核心防护能力。
-
crc32是当前最平衡的选择：硬件支持好、开销低、能捕获绝大多数页损坏 - 若使用老版本 MySQL（如 5.6），且升级困难，至少确保不是
none；可设为innodb，但需知道它已弃用 - 不要手动设为
strict_*类型——它们不是增强版，而是妥协设计，无法在读取时触发崩溃保护
为什么 innodb_checksum_algorithm 影响宕机风险
校验和不只是“检测错误”，它直接决定 InnoDB 遇到损坏页时的行为。关键逻辑是：只有 crc32（或 innodb）能在读取页时校验失败并主动报错（如 InnoDB: Database page corruption on disk），从而阻止错误传播；而 none 或 strict_* 下，损坏页会被当作正常数据加载进缓冲池，后续查询可能返回脏数据、主键冲突，甚至触发断言失败导致 mysqld crash。
- 日志里出现
page corruption不是坏事，说明校验机制起效了，此时还能靠innodb_force_recovery抢救 - 真正危险的是“没报错但结果错”——比如 UPDATE 覆盖了错误行、SELECT 返回空或重复记录，这类问题很难回溯
- Azure Database for MySQL 等托管服务强制使用
crc32，正是因为它的崩溃可预测性
检查和修改 checksum 配置的实操步骤
别只看配置文件，运行时值才真实有效。很多线上库仍沿用旧配置，或被启动脚本覆盖。
- 查当前生效值：
SELECT @@innodb_checksum_algorithm; - 查是否被动态修改过：
SHOW VARIABLES LIKE 'innodb_checksum_algorithm';（注意：该变量不可动态 SET，必须重启生效） - 修改配置文件（如
/etc/my.cnf）中的[mysqld]段：innodb_checksum_algorithm = crc32 - 重启前务必确认：备份
ibdata1和所有.ibd文件——改 checksum 算法本身不会损坏数据，但重启过程会重写系统表空间头，异常中断可能导致更糟后果
容易被忽略的关联配置
innodb_checksum_algorithm 不是孤立参数。它和 innodb_page_size、innodb_log_checksums 共同构成页级防护链。其中最容易翻车的是后者：
-
innodb_log_checksums控制 redo log 的校验，默认为ON（MySQL 8.0.1+），必须保持开启；设为OFF会导致崩溃恢复时跳过日志校验，极大增加数据不一致概率 - 如果
innodb_page_size是 64K（极少见），crc32仍可用，但某些旧内核驱动可能不兼容，需实测 - 监控项别漏掉：
Innodb_data_reads异常升高 +Innodb_buffer_pool_reads同步上升，可能是校验失败后反复重读损坏页的征兆
真正要防的不是“某次损坏”，而是“损坏后无感知蔓延”。crc32 校验本身不防止损坏发生，但它决定了你是在日志里看到一行报错，还是在凌晨三点收到业务报警说订单重复扣款。
