必须停库后才能删.ibd文件，否则mysql启动必报错甚至崩溃；需先drop table清除数据字典，再确认information_schema中无残留，严禁删除ibdata1、ib_logfile0等系统文件。
直接删 .ibd 文件前必须停库，否则 MySQL 启动必报错
哪怕你只是删掉一个孤立的 old_log_2022.ibd，只要 mysqld 还在运行，InnoDB 就可能正在读它的元数据、校验 LSN 或持有文件句柄。轻则启动时卡在 recovery 阶段，重则整个实例崩溃，错误类似：InnoDB: Database page corruption on disk 或 Cannot continue operation。
停库不能只靠 kill -9 或 docker stop 就完事——得确认进程真退出了：
-
systemctl stop mysql后执行ps aux | grep mysqld，输出应为空 - 若用 Docker，进容器跑
mysqladmin ping应返回mysqld is alive才算真活；再查/var/lib/mysql/mysqld.pid是否还存在 - 特别注意：
innodb_fast_shutdown = 1（默认）会跳过部分清理，建议先连上库执行SET GLOBAL innodb_fast_shutdown = 0;，再SHUTDOWN;
删 .ibd 前必须确认表已从数据字典中清除
如果对应表还在 information_schema.tables 里，InnoDB 会在启动时尝试加载它，但文件又没了，直接触发断言失败或 crash。所以顺序不能乱：
- 先执行
DROP TABLE your_table_name;—— 这步会把表从数据字典移除，并标记.ibd可删 - 再查一遍：
SELECT table_name FROM information_schema.tables WHERE table_schema = 'your_db' AND table_name = 'your_table_name';，结果必须为空 - 如果表被外键引用，
DROP会报ERROR 1701，得先SET FOREIGN_KEY_CHECKS = 0;，删完立刻= 1 - 不确定是否残留？别猜，直接
SELECT * FROM information_schema.innodb_sys_tables WHERE name LIKE '%your_table%';查 InnoDB 内部字典
哪些 .ibd 文件能删，哪些绝对不能碰
不是所有带 .ibd 后缀的文件都属于用户表。误删系统级文件会导致 MySQL 根本启不来：
- 安全可删：
your_old_db_archive_2021.ibd、tmp_report_data.ibd（明确命名的老/临时表）、ibtmp1（停库后删，重启自建） - 严禁手删：
ibdata1（存数据字典、undo、系统表）、ib_logfile0（redo 日志）、mysql/全目录（含权限表）、sys/和performance_schema/目录下的任何.ibd - 不确定就
mv到临时目录，比如：mv /var/lib/mysql/your_db/suspicious_table.ibd /tmp/stash/，观察 48 小时无异常再rm -rf
删完别急着重启，先验证备份和路径完整性
物理删 .ibd 是不可逆操作。删之前没备份，等于裸奔；删之后不核对，等于埋雷：
- 备份必须包含完整 InnoDB 系统文件：
ibdata1、ib_logfile*、mysql/、sys/、performance_schema/，缺一不可。只 taryour_db/目录是无效备份 - 删完检查：
tar -tzf backup.tgz | grep -E '\.(ibd|ibdata|ib_logfile)'，确保关键文件都在 - 对比数量：
find /var/lib/mysql -name "*.ibd" | wc -l和备份包内.ibd数量是否一致 - 重启后第一件事：
mysqlcheck -u root -p --all-databases --check，看有没有error : Table 'xxx' doesn't exist类报错
真正危险的不是“删”这个动作，而是删之前没确认表已卸载、删之后没验证字典一致性——这两步漏掉任意一个，恢复时大概率面对的是空库或无法启动的实例。
