DROP TABLE 在从库报错1032/1062/1146，主因是从库表缺失、结构不一致或GTID同步中断；应先验证从库表存在性与结构一致性，再操作，禁用sql_log_bin手动删表，GTID模式下优先用pt-slave-restart恢复。
为什么 DROP TABLE 在从库报错：1032 / 1062 / 1146？
主从复制中执行 DROP TABLE 后从库报错，大概率不是语句本身有问题，而是该表在从库上早已不存在、结构不一致，或被其他同步规则干扰。MySQL 复制是「重放」主库 binlog，如果从库缺失对应表，DROP TABLE 就会失败并中断 SQL 线程。
- 常见错误：
ERROR 1032 (HY000): Can't find record in 'xxx'（实际多见于 UPDATE/DELETE，但 DROP 前隐式检查可能触发） -
ERROR 1146 (42S02): Table 'db.xxx' doesn't exist—— 最典型，说明从库没这张表，但主库发了 DROP -
ERROR 1062 (23000): Duplicate entry—— 少见，但若之前手动建过同名空表、又没清理 relay log，可能因唯一键冲突卡住
用 replicate-ignore-db 或 replicate-wild-ignore-table 过滤删除操作？
不能靠「过滤删除语句」来避免问题——MySQL 不提供按 SQL 类型（如只过滤 DROP）的复制过滤机制。所有基于库/表名的过滤，都是对「事件是否写入 relay log」起作用，而 DROP TABLE 本身是 DDL，只要匹配过滤规则，整条语句就不会到达从库，自然也不会报错。但风险在于：你本意是跳过某张临时表的删除，结果连建表、插入等操作也一并跳过，导致从库数据彻底失联。
-
replicate-ignore-db = test：忽略整个库的所有语句，但注意——它只对USE test后的语句生效，跨库操作（如DROP TABLE prod.tmp_log）仍会执行 -
replicate-wild-ignore-table = %.tmp_%：更可靠，匹配表名模式，DROP TABLE app.tmp_session_2024会被跳过 - 必须在从库
my.cnf中配置，并重启 MySQL 或执行STOP SLAVE; CHANGE REPLICATION FILTER ...; START SLAVE; - 过滤规则只影响 IO 线程写 relay log 的行为，不影响主库 binlog 生成
真正安全的删除流程：先确认从库状态，再操作
靠配置过滤是兜底手段，不是日常操作习惯。生产环境中，任何涉及 DDL 的操作都应前置验证从库一致性，尤其对计划删除的表。
- 在主库执行
SHOW CREATE TABLE db.tbl_name\G，然后到从库执行同样命令，确认输出一致（包括 ENGINE、COLLATION、分区信息） - 查从库是否存在该表：
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='db' AND table_name='tbl_name';—— 返回 0 才能放心删 - 如果从库表已丢失但复制正常，优先查
SHOW SLAVE STATUS\G中的Seconds_Behind_Master和SQL_Remaining_Delay，排除延迟导致的“假缺失” - 禁用
sql_log_bin=0在从库手动删表是危险操作，会破坏 GTID 一致性，且下次主库重发该语句时必然报错
GTID 模式下 DROP TABLE 报错后如何恢复？
GTID 环境中，一旦 SQL 线程因 DROP TABLE 报错停止，Retrieved_Gtid_Set 和 Executed_Gtid_Set 出现缺口，简单跳过事务（SET GLOBAL gtid_next='xxx'）极易引发后续主键冲突或数据覆盖。
- 首选方案：用
pt-slave-restart自动跳过报错事务（需提前安装 Percona Toolkit） - 手动跳过需严格按步骤：
STOP SLAVE; SET GTID_NEXT='xxx-yyy-zzz:nnn'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE;—— 其中xxx-yyy-zzz:nnn必须是从SHOW SLAVE STATUS\G的Retrieved_Gtid_Set中取下一个未执行的 GTID - 切忌用
slave_skip_errors，它会掩盖真实问题，比如本该失败的约束冲突被跳过，导致主从数据逻辑不一致
最常被忽略的一点：很多团队把「从库只读」当万能保险，却忘了 read_only=ON 对 SUPER 权限用户无效。运维或监控脚本若用 root 连从库执行清理，照样会删表——而这不会写入 binlog，主库毫不知情，复制链路从此静默断裂。
