MySQL报错“Table exists”但SHOW TABLES看不到表，通常是数据字典与物理文件不一致所致；需通过INFORMATION_SCHEMA查询字典记录，并检查datadir下对应.ibd/.cfg等文件存在性来交叉验证，再按不一致类型选择DISCARD/IMPORT TABLESPACE或系统表修复。
MySQL 报错 “Table exists” 但 SHOW TABLES 看不到表？先别删库，大概率是数据字典和物理文件不一致
这类报错常见于异常断电、强制 kill mysqld、或手动移动/替换过 .ibd 文件后。MySQL 认为表存在（数据字典里有记录），但实际查不到元信息，或者反之——物理文件残留但字典已删。直接建表会报 ERROR 1050 (42S01): Table 'xxx' already exists，而 DROP TABLE 又提示 ERROR 1051 (42S02): Unknown table。
怎么确认是不是数据字典 vs 物理文件不一致？
分两步交叉验证：
- 查数据字典：
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';—— 如果返回结果，说明字典里还记着这张表 - 查物理文件：进 MySQL 数据目录（
datadir，可通过SHOW VARIABLES LIKE 'datadir';查），定位到对应数据库子目录，看是否存在your_table.frm（5.7 及以前）或your_table.ibd+your_table.cfg（8.0+）等文件 - 特别注意：MySQL 8.0 启用原子 DDL 后，
INFORMATION_SCHEMA和mysql.ibdata1中的系统表（如mysql.tables）才是唯一权威来源；.frm文件已废弃，不能作为判断依据
修复策略取决于不一致类型
常见组合及操作：
-
字典有、物理无（
SHOW TABLES不显示，但INFORMATION_SCHEMA有记录）：执行DROP TABLE your_db.your_table;通常失败；此时应使用ALTER TABLE your_db.your_table DISCARD TABLESPACE;（仅限独立表空间），再手动清理残留元数据（风险高，建议先备份mysql库） -
物理有、字典无（磁盘上有
.ibd，但INFORMATION_SCHEMA查不到）：可尝试CREATE TABLE ... ENGINE=InnoDB;后立刻DISCARD TABLESPACE;，再用IMPORT TABLESPACE;恢复——前提是.ibd文件未损坏且ROW_FORMAT/STATS_PERSISTENT等属性匹配原表定义 - 更稳妥的做法：用
mysqld --bootstrap启动实例，手工插入/删除mysql.tables和mysql.table_stats对应行（仅限 8.0+，需关闭innodb_force_recovery且熟悉系统表结构）
预防比修复更重要：哪些操作容易引发这种不一致？
以下行为在生产环境务必规避：
- 直接
rm -f或mv数据目录下的.ibd/.cfg文件 - 在 MySQL 运行时，用操作系统命令复制或覆盖表空间文件
- 未停服就修改
innodb_file_per_table并执行ALTER TABLE ... ENGINE=InnoDB; - 使用
innodb_force_recovery > 0启动后执行写操作（该模式下 DDL 不被允许，强行操作极易破坏字典一致性）
真正棘手的不是报错本身，而是错误发生后你还继续往里写数据——这时候字典偏移、页校验、事务链可能已经错位。恢复前务必停止所有写入，并确认最近一次可用的逻辑备份或 binlog 位置。
