mysql延时从库通过change master to设置master_delay参数实现，单位为秒，需先stop slave再配置并start slave；sql_delay和sql_remaining_delay反映延迟状态，但受sql线程阻塞影响，不保证恒定滞后。
MySQL 延时从库怎么设（基于 CHANGE MASTER TO）
延时从库不是靠某个开关一键开启，而是通过 CHANGE MASTER TO 指令设置 MASTER_DELAY 参数实现的。这个值单位是秒，表示从库 SQL 线程比主库晚多少秒执行 relay log 里的事件。
实操前注意：必须确保从库已正常启动复制（START SLAVE），且 Seconds_Behind_Master 显示为 0 或稳定值；否则设了延迟也未必准。
- 停掉复制：
STOP SLAVE; - 设置 3600 秒（1 小时）延迟：
CHANGE MASTER TO MASTER_DELAY = 3600; - 重启复制：
START SLAVE; - 验证是否生效：
SHOW SLAVE STATUSG，检查SQL_Delay和SQL_Remaining_Delay字段
为什么 SET GLOBAL slave_net_timeout 不影响延时逻辑
slave_net_timeout 控制的是 IO 线程重连主库的超时时间，和 SQL 线程的执行节奏完全无关。有人误以为调大它能“让延迟更稳”，其实只是让网络断开后重连慢一点，对 MASTER_DELAY 的行为没任何干预作用。
真正影响延时准确性的，是 SQL 线程本身是否被阻塞（比如大事务、锁等待、磁盘 I/O 瓶颈）。一旦 SQL 线程卡住，SQL_Remaining_Delay 可能显示非预期值，甚至归零。
- 延迟不等于“恒定滞后”，它只约束 SQL 线程的启动时机，不控制执行速度
- 如果主库刚执行完一个耗时 2 小时的
UPDATE，从库即使设了 1 小时延迟，也要等这 2 小时跑完才追上 -
SQL_Remaining_Delay为NULL表示 SQL 线程未运行（如被STOP SLAVE SQL_THREAD停过）
误删后如何用延时从库快速回滚
延时从库的核心价值不是“一直慢”，而是在误操作发生后，抢在延迟窗口内暂停 SQL 线程，把数据捞出来。关键动作是“停”和“导出”，不是“等它自己追上”。
假设误删发生在主库 T=15:00，你设了 3600 秒延迟，那么从库当前执行到 T=14:00 的位置——只要还没执行到那条 DROP table，就还有救。
- 立刻在从库执行：
STOP SLAVE SQL_THREAD;（只停 SQL，保留 IO 继续收日志） - 查当前执行点：
SHOW SLAVE STATUSG，关注Relay_Master_Log_File和Exec_Master_Log_Pos - 用
mysqlbinlog解析对应 binlog 文件，跳过误操作语句，生成补救 SQL - 或直接从从库 mysqldump 出对应表（需确认该表尚未被误操作波及）
常见踩坑：MASTER_DELAY 设了但 SHOW SLAVE STATUS 里没反应
最常见原因是复制线程没真正运行起来，或者权限不足。MySQL 不会报错，但参数不会生效。
先确认基础状态：SHOW SLAVE STATUSG 中 Slave_IO_Running 和 Slave_SQL_Running 都要是 Yes；再看 SQL_Delay 是否等于你设的值。如果不是，大概率是命令没生效或被覆盖。
- 检查是否在多源复制环境下误设了错误的 channel：
CHANGE MASTER TO MASTER_DELAY = 3600 for CHANNEL 'xxx'; - 确认没有其他配置文件（如 my.cnf）里写了
slave-skip-errors或replicate-ignore-db导致 SQL 线程异常退出 - MySQL 5.6+ 才支持
MASTER_DELAY，5.5 及更早版本不识别该参数，也不会提示 - 设完不
START SLAVE，SQL_Delay会显示但实际不触发延迟逻辑
延时从库不是保险柜，它是时间缓冲带——依赖你对那个“窗口期”的感知力和响应速度。一旦 SQL 线程跨过误操作点，再想拉回来，就得翻 binlog 或备份了。