确认数据库名和表名是否拼写正确
MySQL 报错
ERROR 1146 (42S02): Table 'db_name.table_name' doesn't exist最常见的原因是大小写或拼写错误。Linux 系统下 MySQL 默认区分表名大小写（由
lower_case_table_names系统变量控制），而 Windows 不区分。如果你在开发机（Windows）建的表叫
User，部署到 Linux 服务器时执行
SELECT * FROM user就可能报 1146。
实操建议：
用SHOW DATABASES;确认当前连接的是不是目标库 用
USE db_name;切换后，再执行
SHOW TABLES;查看真实存在的表名（注意大小写） 检查 SQL 中的表名是否与
SHOW TABLES输出完全一致，包括下划线、数字、大小写 如果应用中用了 ORM（如 Laravel Eloquent 或 Django ORM），确认模型类对应的
$table属性或
Meta.db_table是否写错
检查表是否被意外删除或未成功创建
有时候表确实不存在——不是名字错了，而是根本没建出来。常见于自动化脚本中断、迁移失败、或手动删库没同步更新代码。
实操建议：
查 MySQL 错误日志（路径通常为/var/log/mysql/error.log或
mysqld.err），看建表语句是否报过语法错误（比如字段类型写成
string而非
VARCHAR） 检查建表 SQL 是否被注释、条件跳过，或被
IF NOT EXISTS掩盖了失败（它不会报错，但也不会重建损坏的表结构） 运行
SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name';，结果为 0 就说明真没了 若依赖迁移工具（如 Flyway、Liquibase、Django
migrate），先跑
show migrations或查
flyway_schema_history表，确认对应版本是否已标记为“成功”
确认当前用户是否有访问该表的权限
严格来说，权限不足报的是
ERROR 1142 (42000): SELECT command denied to user...，但某些配置下（尤其搭配代理或中间件），会掩盖真实错误并统一返回 1146。尤其在使用 RDS、云数据库或读写分离架构时容易出现。
实操建议：
用高权限账号（如root）登录，执行
SHOW GRANTS FOR 'user'@'host';，确认是否包含
SELECT ON db_name.table_name或至少
SELECT ON db_name.*如果表在系统库（如
mysql、
performance_schema），普通用户默认无权访问，强行查询也会被拒绝——但部分客户端可能把拒绝误报为“不存在” 在连接字符串里显式指定
database=db_name，避免因默认库不对导致跨库查询失败
InnoDB 表结构文件丢失或损坏
当 MySQL 使用 InnoDB 引擎且启用了
innodb_file_per_table=ON（默认），每张表对应一个
.ibd文件。如果这个文件被误删、chmod 错误、或磁盘损坏，即使
information_schema还残留元数据，MySQL 启动时无法加载表，后续查询就会报 1146。
实操建议：
进数据目录（datadir，可通过
SHOW VARIABLES LIKE 'datadir';查），找对应库目录下的
table_name.ibd和
table_name.frm（5.7 及以前）或
table_name.sdi（8.0+）。缺任何一个都可能出问题 别直接复制
.ibd文件恢复——InnoDB 有事务日志和表空间 ID 校验，必须配合
ALTER TABLE ... IMPORT TABLESPACE流程 若确定文件丢失且无备份，唯一办法是用
mysqldump导出其他环境同结构表，再重建；或者从 binlog 解析出建表和插入语句（前提是你开了
binlog_format=ROW且保留足够久）
真正棘手的情况往往不是单一原因：比如表名拼错 + 权限受限 + 开发环境大小写忽略，导致本地能跑线上全挂。查 1146 时，别只盯着 SQL 本身，要一层层剥开连接、权限、文件、元数据这四层皮。
