MySQL报错“Table doesn't exist”但SHOW TABLES可见，主因是元数据与物理文件不一致：InnoDB表的.frm残留而.ibd缺失或数据字典未同步，常见于误删.ibd、跨实例拷贝未IMPORT、权限不足、SELinux限制或大小写敏感导致。
MySQL报错 Table doesn't exist 但表明明在 SHOW TABLES 里
这是典型元数据与物理文件不一致：InnoDB 表的 .frm 文件可能残留，但 ibdata1 或独立表空间里没对应段。常见于直接删了 .ibd 文件却没用 DROP TABLE，或从其他实例拷过文件但没执行 IMPORT TABLESPACE。
实操建议：
- 先查表引擎：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='tbl_name';—— 如果是InnoDB，别碰.frm，重点看.ibd和数据字典 - 进 MySQL 数据目录（
datadir，用SELECT @@datadir;确认），检查对应库目录下是否有tbl_name.frm和tbl_name.ibd - 若只有
.frm没.ibd，且确认无备份，基本只能重建表结构 + 丢数据；若有.ibd但报错，可能是权限或孤立表空间，需ALTER TABLE tbl_name DISCARD TABLESPACE;再IMPORT
误删 .ibd 文件后，mysqld 启不起来
MySQL 启动时会校验 InnoDB 表空间一致性。如果 ibdata1 记录了某张表，但磁盘上找不到 .ibd，服务大概率卡在初始化阶段，错误日志里会出现 Operating system error number 2 in a file operation 或 Could not open or create data files。
实操建议：
- 别急着重启：先看错误日志（
mysqld.err，路径由log_error配置项决定），定位具体缺失哪个表空间 - 临时绕过：在
my.cnf的[mysqld]段加innodb_force_recovery = 1（数值 1–6，从 1 开始试），再启动 —— 注意：此模式下禁止写入，仅用于导出数据 - 恢复后必须立刻
mysqldump出有效数据，然后删掉整个datadir重建实例，再导入 —— 别试图“修好”损坏的ibdata1
datadir 权限不对导致表“消失”
Linux 下常见：MySQL 进程用户（通常是 mysql）对 datadir 或其子目录没有读/执行权限，会导致它扫描不到库目录，进而 SHOW DATABASES 不显示库、USE db 报错、查表直接 Table doesn't exist，哪怕文件全在。
实操建议：
- 用
ps aux | grep mysqld看进程属主，再ls -ld /var/lib/mysql和/var/lib/mysql/your_db—— 目录需至少有r-x给 mysql 用户 - 修复命令：
sudo chown -R mysql:mysql /var/lib/mysql（路径按实际@@datadir调整），再sudo chmod 750 /var/lib/mysql/your_db - 特别注意 SELinux：CentOS/RHEL 上即使权限对了也起不来，得确认
sestatus状态，必要时sudo setsebool -P mysqld_disable_transitive 1或重打上下文：sudo restorecon -Rv /var/lib/mysql
复制数据库文件后，新实例里表名大小写敏感引发“不存在”
Windows 默认不区分表名大小写，Linux 默认区分。如果把 Windows 备份的 mydb/UserInfo.ibd 直接拷到 Linux 的 datadir，而应用代码里写的是 SELECT * FROM userinfo;，就会报 Table 'mydb.userinfo' doesn't exist —— 因为文件系统里是 UserInfo.ibd，但 MySQL 尝试找小写的 userinfo。
实操建议：
- 检查当前行为：
SELECT @@lower_case_table_names;——0表示区分，1表示不区分（转小写存储） - 跨平台迁移必须统一：在目标实例的
my.cnf里设lower_case_table_names=1，且该值必须在初始化实例前就配置好，运行中不可改 - 已有混用情况？别硬改配置：用
RENAME TABLE UserInfo TO userinfo;批量标准化，再同步更新所有 SQL 和 ORM 映射
最麻烦的不是找不到表，而是你以为找到了——比如 SHOW TABLES 显示了，但 DESCRIBE 报错，或者查询返回空结果。这时候往往已经进了元数据和文件状态错位的深水区，优先保日志、保错误上下文，别靠猜。
