不能直接改配置让旧表“自动变小写”，lower_case_table_names=1重启后仅影响新表，旧表物理文件名（如UserInfo.frm）仍为大写，MySQL按小写userinfo.frm查找失败，导致“Table doesn't exist”；DROP DATABASE时还会残留大写.frm文件，造成“可见不可查”假象。
不能直接改配置让旧表“自动变小写”——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 中表名保持原样，导入时由新规则统一转小写处理
不重启怎么临时绕过？开发阶段最省事的方案
如果你只是想让现有库跑起来、不打算动底层配置，唯一可靠方式是人工统一表名大小写：
- 先用
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`，并强制团队代码规范 —— 因为参数可以配错，但人写对一次，就少踩十次坑。
