MySQL表名大小写敏感由lower_case_table_names变量决定，Linux默认0（区分），macOS/Windows默认1（不区分）；该值启动时读取且不可动态修改，改为1需重命名文件、清理元数据并重启。
MySQL 表名大小写敏感的根本原因在哪
表名是否区分大小写，完全由 lower_case_table_names 系统变量控制，和操作系统无关——但它的默认值又恰恰依赖操作系统。Linux 默认是 0（区分大小写），macOS（默认用 APFS）和 Windows 默认是 1（不区分，自动转小写）。这不是 bug，是 MySQL 故意设计的兼容策略。
关键点在于：这个变量是**启动时读取的，运行中不可修改**，改了要重启 mysqld，且一旦设为 1，所有新创建的表名都会被强制转成小写存入磁盘，后续用大写查会失败（即使 SQL 里写了 SELECT * FROM User）。
如何安全地把 lower_case_table_names 从 0 改成 1
不能直接改配置重启——已有表名含大写字母时，MySQL 启动会报错：Table 'xxx' doesn't exist，因为磁盘上文件名是 User.frm，但 MySQL 按 user.frm 去找。
- 先用
mysqldump导出全部数据库（确保导出语句里的表名是实际大小写，别加--skip-extended-insert导致换行混乱） - 停库，修改 my.cnf，在
[mysqld]下添加lower_case_table_names=1 - 手动重命名数据目录下的所有表文件，把
.frm、.ibd文件名全转成小写（例如User.frm→user.frm） - 清空
mysql系统库中的tables、columns等表里残留的大写表名记录（更稳妥做法是删掉整个mysql目录并用mysqld --initialize重建，再导入权限） - 重启，再用
source导入 dump 文件
lower_case_table_names=2 在 macOS 上为什么危险
2 表示“存储用原大小写，比较时不区分”，听起来灵活，但实际埋雷：
- 跨平台迁移时极易出错：Linux 服务器若设为
0，而你本地开发用2，SQL 里写JOIN User u ON u.id = p.user_id，上线后可能因大小写不一致直接报Unknown table 'User' - MySQL 8.0+ 对
2的支持已弱化，官方文档明确标注“不推荐用于新部署” - 触发器、视图、存储过程里引用的表名，一旦混用大小写，后期排查成本极高——错误提示不会告诉你“是你写错了大小写”，只会说
Table doesn't exist
应用层怎么绕过这个问题不改配置
最省事的办法不是动 MySQL，而是统一约束代码和建表行为：
- 所有建表语句用反引号包裹表名：
CREATE TABLE `user_profile` (…)，避免关键字冲突，也规避大小写歧义 - ORM 配置里显式指定表名小写，比如 Django 的
db_table = 'order_item'，Laravel 的$table = 'product_sku'; - CI 流程中加检查：用
SELECT table_name FROM information_schema.tables WHERE table_schema = 'your_db'扫描是否存在大写字母，有则 fail - 如果必须兼容旧系统，就接受
lower_case_table_names=1，并把迁移脚本里的所有表名统一小写，别留侥幸心理
真正麻烦的从来不是改一个配置，而是改完之后发现上下游服务、ETL 脚本、BI 工具连的还是旧表名——那些散落在各处的字符串才是最不容易被 grep 到的。
