DROP TABLE 本身不直接影响从库查询能力，但会让从库 SQL 线程中断、同步停滞，进而导致后续所有查询看到的是过期数据——这才是“影响查询”的真实原因。
DROP TABLE 本身不直接影响从库查询能力，但会让从库 SQL 线程中断、同步停滞，进而导致后续所有查询看到的是过期数据——这才是“影响查询”的真实原因。
从库执行 DROP TABLE 报错直接卡死 SQL 线程
主库发一条 DROP TABLE db.t1，从库重放时若发现表不存在，立刻报 ERROR 1146 (42S02): Table 'db.t1' doesn't exist，SQL 线程立即停止。此后所有新 binlog 事件都积压在 relay log 里，不再应用。
- 从库的
SHOW SLAVE STATUS\G中Slave_SQL_Running变为No，Seconds_Behind_Master持续上涨 - 业务查从库时，读到的是“卡住那一刻”的快照，不是最新状态；如果该表被频繁 JOIN 或作为视图基础，查询可能直接失败（如
Table doesn't exist） - 注意：这不是查询性能变慢，而是数据停滞 + 可能的元数据缺失引发的逻辑错误
误删后手动补表会放大不一致风险
有人在从库看到 1146 错误后，立刻在从库手动执行 CREATE TABLE 补上，以为能恢复同步——这是危险操作。
- 从库建表不会写入 binlog（
sql_log_bin=1时），主库完全无感知，后续 DML 同步可能因字段顺序、默认值、字符集等细微差异而失败 - 如果主库后续又对该表做了
ALTER TABLE，从库因结构不一致会再次报错（如ERROR 1032或1054） - 更隐蔽的问题：从库补的表没有主键或索引，后续同表的
DELETE/UPDATE在从库变成全表扫描，拖垮 SQL 线程性能
过滤 DROP 语句不能解决根本问题
想靠 replicate-wild-ignore-table = %.tmp_% 这类配置跳过临时表的 DROP？它只对 IO 线程生效，且是“整条语句不进 relay log”，但副作用明显：
- 你跳过了
DROP TABLE tmp_log，同时也跳过了之前所有对tmp_log的INSERT和CREATE TABLE，从库压根没这张表，DROP自然不报错——但数据已失联 - 该配置必须在从库
my.cnf中设置并重启，或动态执行CHANGE REPLICATION FILTER，线上环境改配置有风险 - 它无法区分“该删”和“不该删”：比如
prod.orders_2024_bak和prod.orders都匹配%.bak，后者被误过滤就出大事
真正要命的点不在 DROP 语句本身，而在于它暴露了主从之间长期存在的结构漂移——比如从库漏同步了某次 CREATE TABLE，或者 DBA 手动删过表但没通知运维。这类问题往往在第一次 DROP 时才浮出水面，但根子早在几个月前就埋下了。
