还原sql时报“table 'xxx' doesn't exist”根本原因是lower_case_table_names配置不匹配，必须在目标库首次启动前设为1，否则旧表物理文件名不会自动转换，需停服清空datadir重建或逐个rename table修复。
还原 SQL 文件时报 “Table 'xxx' doesn't exist”，基本就是 lower_case_table_names 配置不匹配导致的，不是 SQL 文件有问题，也不是你导出错了。
为什么 mysqldump 恢复时突然找不到表
典型场景：你在 Windows 上用 mysqldump 导出一个叫 UserProfile 的表，文件里写的是 CREATE TABLE UserProfile；但目标库是 Linux，默认 lower_case_table_names=0，它会严格按大小写去找 UserProfile.frm。而实际磁盘上，如果源库是 Windows（=1），文件名早被存成了小写的 userprofile.frm —— 找不到是必然结果。
更麻烦的是：SHOW TABLES; 可能还显示 UserProfile，因为元数据没删，但一查就报错，属于“可见不可用”。
- Linux 下
lower_case_file_system = OFF（即文件系统本身区分大小写）是前提 -
SELECT @@lower_case_table_names;返回1只说明参数已加载，不代表旧表文件名自动改了 -
mysqldump生成的 SQL 不带大小写转换逻辑，它照抄元数据里的名字
还原前必须确认并统一 lower_case_table_names 值
这个参数不能热修改，必须停服务、改配置、清空或重建 datadir 才安全。生产环境最稳妥的做法是：在目标 MySQL 第一次启动前就设好 lower_case_table_names=1。
- 先停服务：
sudo systemctl stop mysql - 确认
datadir为空：ls /var/lib/mysql/应无数据库子目录、ibdata1、ib_logfile* - 编辑
/etc/my.cnf或/etc/mysql/my.cnf，在[mysqld]段下加：lower_case_table_names=1 - 初始化并启动：
sudo mysqld --initialize --user=mysql（或用 systemd 启动），再验证SELECT @@lower_case_table_names;是否为1
注意：MySQL 8.0+ 如果已有数据再改这个值，可能直接拒绝启动，连错误日志都不写全。
已经还原失败，怎么手动修复表名大小写
如果 SQL 文件已执行但大量表查不到，说明表建出来了，但物理文件名和查询期望不一致。此时只能逐个 RENAME TABLE，且必须用反引号包裹原名，否则大写字母会被当语法错误。
- 先查出所有表：
SHOW TABLES IN your_db; - 对比磁盘文件：
ls /var/lib/mysql/your_db/，看实际文件名是UserOrder.frm还是userorder.frm - 对每个需要修正的表，执行：
RENAME TABLE `UserOrder` TO `userorder`; - 如有外键依赖，先执行：
SET FOREIGN_KEY_CHECKS = 0;，改完再设回1 - 别漏掉视图、存储过程、触发器里硬编码的表名，它们不会随
RENAME自动更新
最容易被忽略的一点：lower_case_table_names=1 只影响新创建的表；已存在的表，哪怕参数显示为 1，其磁盘文件名也不会变——你得亲手重命名，没有捷径，也没有自动脚本能绕过这个限制。
