mysql升级后表名大小写冲突的根源是lower_case_table_names配置不一致，根治需在实例首次启动前设为1并配合rename重命名旧表，否则将出现“table doesn't exist”错误。
MySQL升级后表名大小写冲突，本质不是“升级导致”，而是新旧版本默认 lower_case_table_names 值不一致，或升级过程中目标实例未继承源配置。直接改 SQL 语句是临时补救，强制统一 lower_case_table_names=1 才是根治手段——但必须在实例首次启动前完成，且已有表不会自动重命名。
为什么升级后突然报 “Table 'db.UserOrder' doesn't exist”
典型场景：从 MySQL 5.7（Linux 源库，lower_case_table_names=0）升级到 8.0（目标仍是 Linux，默认仍为 0），但中间经过 Docker 部署、云数据库初始化或配置文件覆盖，导致目标实例实际运行时 lower_case_table_names 被设为 1 或 2；或者反过来，原 Windows 环境（默认=1）迁移到新 Linux 实例却没配=1。
关键点：
-
lower_case_table_names是只读变量，SET GLOBAL修改必报 ERROR 1238，无效 - MySQL 8.0 对该参数更严格：若数据目录已存在且含混合大小写表名，启动时检测到
lower_case_table_names=1与现有文件名不匹配，可能拒绝启动或静默失败 -
SHOW TABLES显示的表名，就是磁盘上 .frm/.ibd 文件的实际大小写，不是“逻辑视图”
如何安全地把 lower_case_table_names 设为 1（推荐路径）
这不是“调整”，而是重建兼容性前提。适用于新部署、重装、或可停服的环境：
- 确认目标 MySQL 完全停止：
systemctl is-active mysql返回 inactive，或ps aux | grep mysqld无进程 - 编辑配置文件：
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，在[mysqld]段下添加：lower_case_table_names=1 - ⚠️ 切勿在已有数据的实例上“中途加参数再重启”——MySQL 8.0 可能跳过元数据校验直接崩溃
- 如果是云数据库（如阿里云 RDS、腾讯云 CDB），该参数通常被锁定为 1，无法修改，只能适配
- 重启后执行：
SELECT @@lower_case_table_names;，返回1才算生效
已有大写表名怎么让新规则识别（RENAME 是唯一可靠方式）
配置改完重启，只是让后续新建的表强制小写。原有 UserOrder 表仍以大写形式存在于磁盘，SELECT * FROM `UserOrder` 会失败，因为 MySQL 此时只认 userorder。
必须人工修正：
- 先用
SHOW TABLES;列出所有表，逐个比对大小写 - 对每个需要修正的表，执行：
RENAME TABLE `UserOrder` TO `userorder`;（反引号包裹原名，避免语法错误） - 若有外键、视图、存储过程引用该表名，需先
SET FOREIGN_KEY_CHECKS = 0;，改完再开 - 注意：MyISAM 表的
.frm文件名也必须同步重命名，否则下次启动可能报错
重构 SQL 语句只是权宜之计，且有隐藏风险
如果无法改配置（如用的是托管 MySQL），只能靠代码侧收敛。但这不是“修 bug”，而是引入新约束：
- 所有
CREATE TABLE、INSERT INTO、JOIN中的表名，全部改用小写，例如FROM user_order而非FROM UserOrder - ORM 框架（如 MyBatis 的
@Table(name = "user_order")、Hibernate 的@Table(name = "user_order")）必须同步更新 - Flowable、ShardingSphere 等中间件生成的 SQL，要确认其内置表名是否已小写化（如
act_ge_property而非ACT_GE_PROPERTY） - ⚠️ 危险操作：在 SQL 中加
BINARY或改 collation 解决字段大小写问题，和表名无关，别混用
最易被忽略的一点：开发本地 macOS（lower_case_table_names=2）跑通的 SQL，在 Linux 生产环境（=0）直接失效——不是升级的问题，是环境长期没对齐。统一用小写表名 + lower_case_table_names=1，才能真正跨平台无感。
