mysql报“table doesn't exist”但表实际存在，首要排查大小写敏感性（linux默认lower_case_table_names=0）、库表真实名称、连接默认库、orm缓存、临时表作用域及docker/rds同步问题。
MySQL 报 Table doesn't exist 但表明明在，先查库名大小写敏感性
Linux 下 MySQL 默认开启 lower_case_table_names=0，意味着库名、表名严格区分大小写；Windows 和 macOS 默认为 1（不区分）。如果你在 Linux 服务器上执行 SELECT * FROM MyTable; 报错，但 SHOW TABLES; 能看到 mytable，大概率是大小写对不上。
- 用
SELECT @@lower_case_table_names;确认当前值：0=敏感，1=不敏感（存储小写，查询忽略大小写） - 检查实际建表语句或
SHOW CREATE TABLE `MyTable`;—— 反引号里的名字才是真实存储名 - 临时绕过：统一用小写写 SQL，比如把
MyDB.UserOrder改成mydb.userorder（前提是库/表确实是以小写创建的） - 注意：修改
lower_case_table_names必须停库、删掉mysql系统库以外的所有.frm/.ibd文件（风险极高），不建议线上操作
用 SHOW DATABASES 和 SHOW TABLES FROM db_name 验证是否存在
别信应用日志里写的库名，也别依赖本地开发环境的记忆。直接连上目标 MySQL 实例，逐层确认：
-
SHOW DATABASES LIKE 'myapp';—— 看库是否存在，注意通配符和大小写 -
USE myapp;成功后，再SHOW TABLES LIKE 'user_profile'; - 如果
USE都失败，说明库名错了，或者用户没权限（SELECT COUNT(*) FROM mysql.db WHERE Db='myapp';可查授权） - 某些 ORM（如 Django）默认加前缀或用下划线命名，比如生成的表叫
auth_user而不是User，得看迁移记录或SHOW CREATE TABLE
连接时指定了错误数据库，或 SQL 里漏写了 database.table 前缀
MySQL 客户端连接时可以指定默认库（mysql -u user -p -D myapp），但如果代码里写的是 SELECT * FROM logs;，而当前 session 没 USE myapp;，就会报错——它会在当前默认库（可能是 information_schema 或空）里找 logs 表。
- 检查连接字符串是否带
database=myapp参数（如 JDBC 的jdbc:mysql://localhost:3306/myapp） - 在 SQL 中显式写全名：
SELECT * FROM myapp.logs;，避免依赖上下文 - PHP 的
mysqli_select_db()或 Python 的cursor.execute("USE myapp")是临时切换，容易遗漏或失效 - Docker 或 RDS 场景下，可能连的是 proxy 或只读实例，该实例未同步新库/表，需确认后端真实节点
表被 DROP 了但应用缓存了旧 schema，或用了分区表/临时表
有些框架（Laravel、SQLAlchemy）会缓存表结构，哪怕你手动 DROP TABLE 了，应用仍尝试访问已不存在的表；另外，临时表（CREATE TEMPORARY TABLE）只在当前 session 生效，断开重连就消失。
- 重启应用进程或清空 ORM 缓存（如 Django 的
./manage.py flush不删表，但migrate --fake-initial可能误判） - 检查是否用了
CREATE TABLE ... PARTITION BY，分区表的子分区名不等于主表名，SHOW TABLES不显示子分区 - 临时表只对当前连接可见：
SELECT * FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'temp' AND TABLE_TYPE = 'TEMPORARY';查不到，因为information_schema不暴露临时表 - 误删系统表（如
mysql.user）也会引发连锁报错，但错误信息通常是Unknown table 'mysql.user'，需用mysql_upgrade修复
最常被忽略的一点：MySQL 8.0+ 默认关闭 innodb_file_per_table 时，删表后空间不释放，但表定义还在 mysql.innodb_table_stats 里残留，导致某些监控脚本误判“表存在”。真要验证，只信 SHOW CREATE TABLE 和磁盘上对应的 .ibd 文件是否存在。
