结论：清空大表禁用DROP TABLE和TRUNCATE TABLE，应改用分批DELETE（需主键）或改名重建；TRUNCATE在从库会重建表结构、锁表并阻塞同步，风险远高于DELETE。
直接说结论：别用 DROP TABLE 或 TRUNCATE TABLE 清空大表，尤其当它没主键、没索引、或在主从架构里——这两条命令在从库上会触发全表扫描或重建，极易卡死SQL线程，导致 Seconds_Behind_Master 爆涨甚至同步中断。
为什么 TRUNCATE 在从库上比 DELETE 更危险
很多人以为 TRUNCATE 是“清空快、不走事务、不写binlog”，其实这是错觉。MySQL 5.7 的 TRUNCATE 在 row 格式复制下仍会生成 binlog 事件（类型为 GTID_LOG_EVENT + QUERY_EVENT），且从库执行时会先删 .ibd 文件、再重建空表结构——这个过程会锁整个表、阻塞其他 DML，同时中继日志（relay log）里的后续事件全部排队等待。更麻烦的是，如果该表被视图/存储过程引用，TRUNCATE 还可能因元数据锁冲突失败。
- 主库执行
TRUNCATE t_large，从库不是“秒级完成”，而是要等ALTER TABLE t_large ENGINE=InnoDB式的重建流程 - 若该表有外键被其他表引用，从库可能报错
ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails -
TRUNCATE不受sql_log_bin=0影响，无法通过关闭 binlog 来规避同步
真正安全的清空方式：分批 DELETE + 主键驱动
前提是这张大表必须有主键（或至少一个非空唯一索引）。没有主键？先加，别跳过这步——否则从库照样全表扫。
- 在主库执行：
DELETE FROM t_large WHERE id BETWEEN ? AND ? LIMIT 10000，每次删 1 万行，用主键范围控制 - 每批之间加
SLEEP(0.1)（可选），避免主库 I/O 压力突增 - 用
SELECT MAX(id) FROM t_large和自增步进控制循环边界，避免漏删 - 确认从库
SHOW SLAVE STATUS\G中Seconds_Behind_Master稳定在 0～2 秒内再执行下一批 - 删完后立刻执行
OPTIMIZE TABLE t_large（仅在从库做），回收碎片、重置 AUTO_INCREMENT
无主键大表的兜底方案：改名 + 重建
如果表确实没主键、又不能停业务加索引，就放弃“在线清空”幻想，改用原子性替换：
- 主库建新表：
CREATE TABLE t_large_new LIKE t_large，然后加好主键 - 把旧表数据按主键范围分批 INSERT INTO t_large_new SELECT ... FROM t_large WHERE ...（同样带 LIMIT）
- 最后用
RENAME TABLE t_large TO t_large_old, t_large_new TO t_large原子切换 - 注意：切换瞬间主库会短暂锁表，但时间极短（毫秒级），且从库只同步
RENAME语句本身，不涉及数据搬运 - 切换后立刻在从库执行
STOP SLAVE; RESET SLAVE ALL;清理残留 relay log，再START SLAVE
最常被忽略的一点：清空前务必确认 binlog_format 是 ROW（不是 MIXED 或 STATEMENT），否则分批 DELETE 在从库可能因函数/变量等非确定性因素执行失败。用 SELECT @@binlog_format; 检查，不一致就改配置并重启从库 mysqld —— 别图省事只改会话级变量。
