MySQL 8.0虽默认启用log_bin，但未配置非零server-id时会静默禁用，导致SELECT @@log_bin返回0；必须在[mysqld]段显式设置server-id=1等有效值，并通过SHOW MASTER STATUS验证是否真正生效。
log_bin 默认已启用，但必须显式配置 server-id 才能真正生效，否则 SHOW MASTER STATUS 会报错或返回空。
为什么设置了 log-bin 却显示 OFF？
MySQL 8.0 虽默认开启 log_bin，但若未设置 server-id，系统会静默禁用 binlog 功能（SELECT @@log_bin 返回 0）。这是常见误判点。
-
server-id必须是非零正整数（如1），且不能与其他节点重复（主从场景下） - 配置必须放在
[mysqld]段，写在[client]或其他段无效 - 路径权限问题：若指定
log-bin = /path/to/mysql-bin，需确保 MySQL 进程对目录有读写权限，否则启动失败或回退到默认 datadir - 验证方式不是只看
log_bin变量，而是执行SHOW MASTER STATUS—— 成功返回文件名和 position 才算真正启用
binlog_format 应该选 ROW 还是 STATEMENT？
生产环境无条件选 ROW。STATEMENT 模式在含非确定性函数（如 NOW()、UUID()）、触发器、存储过程时极易导致主从不一致，且无法被 CDC 工具可靠解析。
-
ROW记录每行变更前后的镜像，复制和恢复精度最高 - 代价是磁盘空间更大，尤其对大字段或批量更新敏感；可通过
binlog_row_image = MINIMAL（MySQL 5.7+）略作压缩，但 8.0 默认已是FULL - 不要混用格式：即使设为
MIXED，MySQL 也仅在极少数语句（如INSERT ... SELECT）自动降级，不可靠
sync-binlog=1 和 expire-logs-days 已过时，该用什么？
MySQL 8.0+ 推荐用 sync_binlog = 1（仍有效），但过期策略必须改用 binlog_expire_logs_seconds + binlog_expire_logs_auto_purge，旧参数 expire_logs_days 仅兼容，不推荐。
-
binlog_expire_logs_seconds = 604800（7 天） +binlog_expire_logs_auto_purge = ON是标准组合 - 注意优先级：
binlog_expire_logs_auto_purge关闭时，binlog_expire_logs_seconds设置无效 - 清理触发时机不固定：发生在
FLUSH LOGS、binlog 切换、或 mysqld 启动时，不是定时任务 - 磁盘空间告警时，别只调大过期时间——先检查
max_binlog_size是否过小（如设成 100M 会导致频繁切换和碎片）
加密 binlog（binlog_encryption=ON）为什么没效果？
启用加密不是加个配置就完事。8.0.14+ 才支持，且依赖 keyring 插件初始化成功；否则日志仍是明文，mysqlbinlog 也能直接解析。
- 必须确认版本：
SELECT VERSION()≥ 8.0.14 -
binlog_encryption是只读变量，只能在配置文件中设：binlog_encryption = ON（[mysqld]下），运行时SET GLOBAL报错 - keyring 插件加载顺序关键：建议在
[mysqld]首行加early-plugin-load = keyring_file.so，再配keyring_file_data = /var/lib/mysql-keyring/keyring - 目录
/var/lib/mysql-keyring需chown mysql:mysql且chmod 0600，否则插件加载失败，错误日志里会出现Keyring service not found
keyring_file_data 文件是否存在、是否为空、是否被 MySQL 进程写入过密钥——它不会自动创建，首次启动时若路径下无文件，keyring_file 插件会静默失败。 
