这是互联网大厂最通用的方案。核心思想是：把“删表”这个重型操作，拆分为“重命名（快）”+“重建（快）”+“后台清理（慢）”三个步骤。

操作 SOP（标准作业程序）

假设我们要删除的表是 my_db.big_table。

第一步：瞬间“移走”大表（关键！）

-- 在业务低峰期执行（如凌晨 2 点）
RENAME TABLE my_db.big_table TO my_db.big_table_to_drop;

• 原理：RENAME TABLE 是一个 DDL 操作，它只修改数据字典（Data Dictionary），不涉及数据搬迁。
• 耗时：毫秒级，几乎瞬间完成。
• 影响：
  • 业务端对 big_table 的请求会立即报错（表不存在）。
  • 对策：配合应用端的“失败重试”机制，或者在维护窗口操作。此时 big_table_to_drop 已经与业务隔离，后续的删除操作再慢也不会影响线上。

第二步：快速重建“空壳”表（可选但推荐）

如果业务不能没有这张表（哪怕是空的），立即重建结构：

CREATE TABLE my_db.big_table LIKE my_db.big_table_to_drop;

• 原理：LIKE 关键字会复制原表的所有索引、字段属性、分区规则，但不复制数据。
• 耗时：极快，只涉及元数据拷贝。
• 效果：业务端现在可以访问 big_table 了，虽然是空的，但服务恢复了。

第三步：后台“慢慢”删除

现在，big_table_to_drop 就像一个被隔离的“垃圾场”，你可以随时处理它，而不用担心影响用户：

-- 可以在当前会话执行，也可以开个新会话在后台执行
-- 甚至可以等到第二天早上再执行
DROP TABLE my_db.big_table_to_drop;

• 注意：此时的 DROP 依然需要清理 1000 万行数据，依然会慢，但因为它已经不在业务链路上了，慢一点又何妨？

1. 遇到外键约束怎么办？

如果大表被外键引用，直接 DROP 会报错。
方案：临时关闭外键检查（仅限 Session 级别，不要全局关闭！）。

SET FOREIGN_KEY_CHECKS = 0;
DROP TABLE my_db.big_table_to_drop;
SET FOREIGN_KEY_CHECKS = 1;

2. 如何释放磁盘空间？

删除表后，你会发现磁盘空间并没有立刻释放。

• 原因：InnoDB 的空间是复用的。如果开启了 innodb_file_per_table=ON（默认开启），删除表后 .ibd 文件会被操作系统回收。
• 特殊情况：如果是系统表空间（ibdata1），空间无法释放给操作系统，只会标记为 InnoDB 内部可用。
• 急救方案：如果必须立刻释放空间，且不怕锁表，可以考虑 OPTIMIZE TABLE（针对剩余表）或者导出数据再重建整个实例（极端情况）。但对于“删表”这个动作本身，通常不需要额外操作，空间会被后续新数据覆盖重用。

3. 绝对不要忘了备份！

在执行 RENAME 之前，哪怕你有 99% 的把握，也要做一次快照：

# 仅备份结构
mysqldump -u root -p --no-data my_db big_table > big_table_structure.sql

# 备份结构+数据（如果磁盘够大）
mysqldump -u root -p my_db big_table > big_table_backup.sql

4. 监控与观察

在执行 DROP TABLE my_db.big_table_to_drop; 时，如何知道进度？

• 查看进程：SHOW PROCESSLIST; 查看状态是否为 cleaning up。
• 查看 IO：使用 iotop 或 iostat 观察磁盘写入是否在进行。
• InnoDB 状态：SHOW ENGINE INNODB STATUS\G 查看 Purge 线程的工作情况。