MySQL报错 Table 'xxx' doesn't exist
怎么快速定位原因
这个错误不一定是表真丢了，更可能是大小写、数据库名、存储引擎或权限层面出了偏差。先别急着查备份，按顺序排查这四类常见源头：
lower_case_table_names配置不一致：Linux 默认区分表名大小写（
lower_case_table_names=0），而 Windows/macOS 默认不区分（
=1）。如果从 Windows 导出的 SQL 在 Linux 上执行，
CREATE TABLE User和后续
SELECT * FROM user就会因大小写不匹配失败 连错了数据库：执行
USE后没生效，或代码里用的是默认库（如
mysql系统库），但实际想查的是
myapp库里的表 表被意外 DROP 或未成功 CREATE：检查建表语句是否含语法错误（比如 MySQL 8.0 不支持
TYPE=MyISAM，必须改用
ENGINE=MyISAM），导致建表静默失败 用户无对应库表权限：即使表存在，
SELECT报这个错也可能是权限不足（尤其使用
GRANT ... ON db.*但忘了
FLUSH PRIVILEGES）
确认表是否真的不存在的三步验证法
别只信报错，用系统表和命令交叉验证：
SHOW DATABASES LIKE 'your_db_name';
确认库存在后，再查表：
USE your_db_name; SHOW TABLES LIKE 'your_table_name';
如果仍为空，直接查
information_schema（它不受当前库影响）：
SELECT table_name FROM information_schema.tables WHERE table_schema = 'your_db_name' AND table_name = 'your_table_name';
注意：
table_schema是数据库名，不是文件路径；如果这里也查不到，基本可断定表确实不存在。
MySQL 8.0+ 中因数据字典变更引发的“假不存在”问题
MySQL 8.0 起用原子性数据字典（Data Dictionary），表元数据统一存于
mysql.ibd，不再依赖 .frm 文件。如果你从 5.7 升级上来，或手动拷贝了表文件（
.ibd+
.frm），会出现“文件在但 MySQL 不认”的情况： 错误日志里可能有
InnoDB: Error: table xxx does not exist in the InnoDB internal data dictionary
SHOW CREATE TABLE报错，但
ls -l /var/lib/mysql/your_db/能看到对应文件 此时不能直接删文件，得用
DROP TABLE IF EXISTS清理字典残留，再用
CREATE TABLE ... IMPORT TABLESPACE重新导入（需提前有
.cfg文件）
开发中容易忽略的大小写陷阱和修复方式
本地开发（macOS/Windows）能跑通的 SQL，上线 Linux 就报错，90% 出在这儿：
检查 MySQL 配置：SELECT @@lower_case_table_names;—— 生产环境建议统一设为
1（重启生效），避免大小写争议 代码里所有表名、字段名用反引号包裹：
SELECT `id`, `user_name` FROM `user_info`，防止关键字冲突或大小写解析歧义 迁移脚本中禁用自动转换：mysqldump 加参数
--skip-set-charset --default-character-set=utf8mb4，避免隐式编码转换干扰表名解析
最稳妥的做法是：建库时就约定全小写+下划线命名，且所有 SQL 严格遵循该规范——这不是风格问题，是跨平台运行的硬性前提。
