binlog_checksum默认值因MySQL版本而异：5.6为NONE，5.7及8.0为CRC32；该变量只读，须在my.cnf中配置并重启生效，主从应统一设为CRC32以避免校验失败导致复制中断。
binlog_checksum 默认值在不同 MySQL 版本中差异很大
MySQL 5.6.6 起引入 binlog_checksum，但默认值随版本跳变：5.6 默认 NONE，5.7 默认 CRC32，8.0 仍为 CRC32。这意味着升级后如果没显式配置，主从复制可能因校验失败中断——尤其当从库是旧版本、或开启了 slave_sql_verify_checksum=ON（8.0 默认开启）时。
- 检查当前值：
SELECT @@binlog_checksum; - 查看是否启用校验验证：
SELECT @@slave_sql_verify_checksum; - 若主从版本不一致，建议统一设为
CRC32，避免隐性兼容问题 -
NONE不代表“更安全”或“更快”，它只是关闭校验，无法发现日志传输/磁盘静默错误
修改 binlog_checksum 必须重启 mysqld 才生效
binlog_checksum 是只读动态变量，SET GLOBAL binlog_checksum = 'CRC32' 会报错 ERROR 1238 (HY000): Variable 'binlog_checksum' is a read only variable。必须写入配置文件并重启服务。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 在
my.cnf的[mysqld]段添加：binlog_checksum = CRC32 - 重启前确认二进制日志已轮转（
FLUSH LOGS;），否则新 checksum 格式会和旧 binlog 文件混用，导致解析失败 - 重启后检查
SHOW BINARY LOGS;中最新日志文件是否开始使用新校验格式（可通过 mysqlbinlog 工具解析头信息验证）
mysqlbinlog 解析带 checksum 的 binlog 会报错 “unknown compression type” 或 “invalid event length”
这是最常见的误操作结果：用低版本 mysqlbinlog（如 MySQL 5.7 自带）去解析 8.0 写入的 CRC32 校验日志。8.0 默认启用了 binlog 压缩（binlog_transaction_compression=ON）且 checksum 与压缩标记耦合，老工具不认识新结构。
- 确保 mysqlbinlog 版本 ≥ 对应服务器版本（推荐用同版本客户端）
- 临时绕过解析失败：加
--base64-output=DECODE-ROWS -v可跳过部分校验逻辑，但无法还原压缩事件 - 真正解决问题：在 8.0+ 上如需兼容旧工具，可关掉压缩：
SET GLOBAL binlog_transaction_compression = OFF;（需配合binlog_checksum=CRC32使用，否则校验仍可能失败）
主从复制中 slave_sql_verify_checksum 导致 SQL 线程意外停止
当从库开启 slave_sql_verify_checksum=ON（8.0.20+ 默认值），而主库 binlog_checksum=NONE，从库读取事件时会因缺失校验字段报错：Slave SQL thread retried transaction ... due to checksum mismatch。
- 最稳妥做法：主从两端都设为
CRC32，且保持slave_sql_verify_checksum=ON - 临时缓解：从库设
slave_sql_verify_checksum=OFF，但会丧失对日志损坏的检测能力 - 注意该变量也是只读动态变量，需在
my.cnf中配置并重启从库 - 该设置不影响 IO 线程，只影响 SQL 线程回放阶段的校验动作
binlog_encryption）存在隐式依赖关系，三者不同步就容易触发看似无关的解析失败或复制中断。调任何一项之前，先确认其他两项的状态。 
