能防误删但仅限5分钟内抢救；必须先STOP SLAVE SQL_THREAD再设MASTER_DELAY，否则报错ERROR 3085；GTID模式下禁用sql_slave_skip_counter，需用START SLAVE UNTIL精确回放。
能防，但只在误删后5分钟内动手才有效；必须先停SQL线程再设延迟，否则直接报错 ERROR 3085。
STOP SLAVE SQL_THREAD 是硬性前置条件
MySQL 8.0 要求必须暂停 SQL 线程才能修改 MASTER_DELAY。直接执行 CHANGE MASTER TO MASTER_DELAY = 3600 会触发拒绝错误，不是警告，无法绕过。
- 正确顺序只有三步：
STOP SLAVE SQL_THREAD;→CHANGE MASTER TO MASTER_DELAY = 3600;→START SLAVE SQL_THREAD; - 只停
SQL_THREAD（保留IO_THREAD继续接收 binlog），避免主库新事件丢失 - 如果从库已运行一段时间，
CHANGE MASTER TO会清空Relay_Master_Log_File和Exec_Master_Log_Pos，务必提前用SHOW SLAVE STATUS\G记下Master_Log_File和Read_Master_Log_Pos，并在CHANGE MASTER TO中显式补全，否则可能从 binlog 开头重放
监控必须盯紧 SQL_Remaining_Delay，不是 Seconds_Behind_Master
Seconds_Behind_Master 是总滞后秒数，和你设的延迟值无关；真正决定“还有没有抢救时间”的字段是 SQL_Remaining_Delay——它是倒计时，仅当 SQL 线程卡在延迟队列里时非 NULL。
- 大事务正在执行（如长 UPDATE），
Seconds_Behind_Master飙到上万，但SQL_Remaining_Delay仍是 3600 → 延迟仍在生效，正常 -
Seconds_Behind_Master = 0，但SQL_Remaining_Delay = 3590→ 实际还在延迟中，只是没积压新事件 - 监控脚本若只查
Seconds_Behind_Master，会误判延迟失效，错过抢救窗口
GTID 模式下严禁用 sql_slave_skip_counter
生产环境基本都启用了 gtid_mode = ON，此时 SET GLOBAL sql_slave_skip_counter = 1 会破坏 GTID 集合一致性，导致复制中断甚至数据错乱。
- 误删发生后，正确做法是：立刻在延迟从库上执行
STOP SLAVE SQL_THREAD; - 用
mysqlbinlog解析中继日志，定位到误删前最后一个事务位置 - 再用
START SLAVE UNTIL SQL_AFTER_GTIDS = 'xxx:yyy'精确回放到那个 GTID - 导出数据后恢复主库，全程不碰
sql_slave_skip_counter
延迟不是固定滞后 N 秒，而是受写入压力与事务大小影响
设了 MASTER_DELAY = 3600 不代表从库永远慢一小时。真实表现取决于主库写入节奏、从库 IO/CPU 负载、以及是否遇到大事务。
- 主库 binlog 切换频繁，而从库还没追上上一个文件 → 延迟波动明显
- 从库执行 DDL 或长事务期间，
Seconds_Behind_Master可能远超 3600，但SQL_Delay字段仍显示配置值 —— 这是设计行为，不是异常 - 延迟复制本质是“给你留出手动抢救时间的缓冲带”，不是自动拦截器；它防不了逻辑错误、人为跳过、或主库硬件故障
最易被忽略的点：延迟从库必须启用 read_only = ON 和 super_read_only = ON，否则误操作可能直接在从库上执行，彻底废掉这层防护。
