如何修复MySQL表名大小写敏感问题_通过lower_case_table

不能直接改配置让旧表“自动变小写”，lower_case_table_names=1重启后仅影响新表，旧表物理文件名（如UserInfo.frm）仍为大写，MySQL按小写userinfo.frm查找失败，导致“Table doesn't exist”；DROP DATABASE时还会残留大写.frm文件，造成“可见不可查”假象。

如何修复mysql表名大小写敏感问题_通过lower_case_table_names设置

不能直接改配置让旧表“自动变小写”——lower_case_table_names 重启后只影响新创建的表，已有表名仍按原大小写存于磁盘，不重命名就无法被新规则识别。

为什么改了 `lower_case_table_names=1` 还报 “Table doesn't exist”

典型现象是：Linux 上迁移 Windows 导出的 SQL（含大写表名），导入后执行 SELECT * FROM UserInfo; 报错。原因不是语法问题，而是物理文件名和内存注册名不一致：

lower_case_table_names=0 时建的 UserInfo，磁盘上存为 UserInfo.frm
改到 =1 后重启，MySQL 会尝试按小写 userinfo.frm 去找文件，但该文件不存在
SHOW TABLES; 可能仍显示 UserInfo，因为元数据里还记着这个名字，但访问失败
更糟的是：如果中间执行过 DROP DATABASE，MySQL 会用小写去删文件，导致大写 .frm 残留，出现“可见却不可查”的假象

线上库不能热改，安全修改必须停服清空再重建

这个变量是只读的：SET GLOBAL lower_case_table_names=1 必报 ERROR 1238。真正生效需满足三个硬性条件：

确认当前 datadir 路径：SELECT @@datadir;
完全停止 MySQL 服务，确保无残留进程（ps aux | grep mysqld）
手动删除 datadir 下所有内容（包括 ibdata1、ib_logfile*、各数据库子目录、mysql 系统库）
在 my.cnf 的 [mysqld] 段写死：lower_case_table_names=1
用 mysqld --initialize 初始化系统表，再启动
旧数据必须重新导入：mysqldump 输出的 SQL 中表名保持原样，导入时由新规则统一转小写处理

不重启怎么临时绕过？开发阶段最省事的方案

如果你只是想让现有库跑起来、不打算动底层配置，唯一可靠方式是人工统一表名大小写：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

先用 SHOW TABLES; 列出所有表，逐个检查是否含大写字母
对每个需修正的表，执行：RENAME TABLE `OldName` TO `oldname`;（注意反引号包裹原名）
外键或视图依赖表名时，先 SET FOREIGN_KEY_CHECKS=0;，重命名完再开回来
批量操作可用存储过程，但要注意：游标内拼接的 RENAME 语句必须用 LOWER() 转小写，且目标库名也得是小写
CI 流程中加检查命令：mysql -Nse "SELECT table_name FROM information_schema.tables WHERE table_schema='your_db' AND table_name REGEXP '[A-Z]'"

Docker 和 macOS 环境特别容易漏掉的点

很多人以为加环境变量就行，其实官方镜像根本不读 MYSQL_LOWER_CASE_TABLE_NAMES；Alpine 镜像默认读 /etc/my.cnf，Debian 版则可能读 /etc/mysql/my.cnf —— 不确认路径就改错地方。

macOS 默认 lower_case_table_names=2，它允许你建 UserTable 并存原样，但查询时自动转小写匹配。这看起来“兼容”，实则埋雷：一旦迁到 Linux（=0），UserTable 和 usertable 就变成两张表，而 dump 导出的 SQL 不带反引号，导入时行为不可控。

真正稳的做法，是从第一天起所有 DDL 都显式用反引号：CREATE TABLE `user_profile`，并强制团队代码规范 —— 因为参数可以配错，但人写对一次，就少踩十次坑。