innodb_checksum_algorithm 需在配置文件中设置并重启生效，设为 none 可禁用页校验提升写入性能但丧失损坏检测能力，MySQL 8.0+ 默认 strict_crc32，SHOW CREATE TABLE 不显示该配置因其属引擎全局行为而非表级属性。
MySQL 中 innodb_checksum_algorithm 怎么改才生效
改表的校验和开关，本质是改 innodb 的全局或会话级校验算法，不是直接“开关”某张表的 checksum 属性——innodb 表本身没有可配置的 checksum 字段或开关。真正起作用的是 innodb_checksum_algorithm 配置项，它控制页校验方式（如 crc32、strict_crc32、none 等）。
常见错误现象：ALTER TABLE t1 CHECKSUM=1 报错或静默忽略，因为该语法只对 MyISAM 有效；对 InnoDB 执行毫无效果。
-
SET GLOBAL innodb_checksum_algorithm = 'none'可禁用校验（但需 SUPER 权限，且实例重启后失效，除非写入配置文件） - 永久生效必须在
my.cnf或mysqld.cnf中设置：innodb_checksum_algorithm = none，然后重启 mysqld - 值为
none时，InnoDB 跳过页校验，写入更快，但丢失损坏检测能力；生产环境不建议设为none - MySQL 8.0+ 默认是
strict_crc32，比旧版crc32更严格，能捕获更多页损坏场景
为什么 SHOW CREATE TABLE 里看不到 checksum 配置
因为 InnoDB 表定义中根本不存储 checksum 相关配置。你看到的 CREATE TABLE 输出里不会有 CHECKSUM=1 或类似字段——那是 MyISAM 的遗留语法，InnoDB 完全不识别。
使用场景：当迁移老 MyISAM 表到 InnoDB 后，发现原来靠 myisamchk --check 验证的流程失效了，误以为要“给 InnoDB 表开 checksum 开关”，其实该转向监控 Innodb_data_reads、Innodb_pages_read 和错误日志里的 Corrupted page 提示。
- MyISAM 的
CHECKSUM=1是表级开关，存于 .MYI 文件头，SHOW CREATE TABLE会显示 - InnoDB 校验是引擎层统一行为，由
innodb_checksum_algorithm控制，与单表无关 - 想验证某张 InnoDB 表是否“被校验”，唯一可靠方式是查
SELECT @@innodb_checksum_algorithm，再配合压测时观察错误日志
innodb_checksum_algorithm=none 的真实影响
设为 none 不只是“关掉校验”，它会让 InnoDB 在读写数据页时跳过 CRC 计算与比对，从而降低 CPU 开销，但代价明确：
- 无法在读取时发现磁盘/RAID/驱动导致的页静默损坏（silent corruption）
- 崩溃恢复阶段失去一页完整性依据，可能把损坏页当作合法页加载，引发后续 SQL 报错甚至数据错乱
- 某些云厂商 RDS（如阿里云 PolarDB、AWS RDS）禁止修改此参数，强制启用
strict_crc32 - 性能提升有限：现代 CPU 上 CRC32 硬件指令极快，实测吞吐下降通常
误操作后怎么快速回退
如果已执行 SET GLOBAL innodb_checksum_algorithm = 'none' 并担心风险，别等重启——立刻切回安全值：
- 执行
SET GLOBAL innodb_checksum_algorithm = 'strict_crc32'（MySQL 5.7+ / 8.0+ 均支持） - 该命令立即生效，新读写的页即开始校验；但已加载到 buffer pool 的旧页仍按原算法处理，无须清空缓存
- 检查是否成功：
SELECT @@innodb_checksum_algorithm应返回strict_crc32 - 若权限不足报错
Access denied for user，说明没 SUPER 权限，只能联系 DBA 或改配置文件后重启
最常被忽略的一点：校验算法变更不影响表结构或数据文件格式，但会影响 ib_logfile 和系统表空间的页校验逻辑——所以即使只是临时测试，也建议在非高峰时段操作，并确认 binlog 和备份链路正常。
