DROP TABLE 卡住业务是因为InnoDB同步清理buffer pool页、刷脏页、删文件等操作串行阻塞；硬链接方案将删文件交由OS异步处理，需四步：确认独立表空间、FLUSH TABLES FOR EXPORT、创建硬链接、DROP TABLE、异步rm硬链接。
直接 DROP TABLE 一个 TB 级的 InnoDB 表，极大概率会让 MySQL 实例卡住几十秒甚至几分钟——不是因为 SQL 执行慢，而是因为 InnoDB 要同步清理 buffer pool 中成千上万页、刷脏页、释放文件句柄、删磁盘文件这一整套动作全被串行锁住。硬链接方案本质是把「删文件」这个高危 IO 操作从 MySQL 进程里剥离出来，交由 OS 异步完成。
为什么 drop table 会卡住线上业务
InnoDB 删除大表时必须做三件事：清空 buffer pool 对应页（持 buf_pool->mutex）、关闭并 unlink .ibd 文件、通知存储引擎释放元数据。其中前两步是同步阻塞的——buffer pool 越大、表的热页越多，持有 mutex 时间越长；同时大量随机 IO 会打满磁盘带宽，拖慢其它查询。你看到的“连接堆积”“复制延迟飙升”，根源就在这里。
硬链接方案实操四步（仅适用于独立表空间）
确认表使用独立表空间：SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE, CREATE_OPTIONS FROM information_schema.TABLES WHERE TABLE_NAME = 'your_table';，输出中含 ROW_FORMAT=COMPACT 或 FILE_PER_TABLE=1 即可继续。
- 在 MySQL 中执行
FLUSH TABLES your_table FOR EXPORT;—— 这会停止对该表的所有写入，并确保 ibd 文件状态一致 - 在 shell 中创建硬链接：
ln /var/lib/mysql/dbname/your_table.ibd /tmp/your_table.ibd.hardlink（路径需严格匹配datadir和实际文件名） - 回到 MySQL 执行
DROP TABLE your_table;—— 此时 MySQL 只删元数据和 .frm/.isl 文件，.ibd因有硬链接存在不会被真正删除 - 在 shell 中异步删除硬链接：
rm /tmp/your_table.ibd.hardlink，系统会在后台逐步回收磁盘块，不干扰 MySQL
常见错误和绕不开的坑
硬链接只对同一文件系统生效，/var/lib/mysql 和 /tmp 不在同一个 mount point 就会失败；FLUSH TABLES ... FOR EXPORT 要求表无活跃事务，否则会 hang 住；MySQL 5.6 及更早版本不支持该语法，必须升级；如果表启用了加密（ENCRYPTION='Y'），硬链接后删除可能触发密钥管理异常。
真正难的不是操作步骤，而是判断“现在能不能停写几秒”。FLUSH TABLES ... FOR EXPORT 是个全局读锁，哪怕只持续 200ms，对高并发写入服务也是风险点。所以生产环境务必先在低峰期试跑，监控 SHOW PROCESSLIST 和 innodb_buffer_pool_pages_dirty 变化趋势。
