mysql表名是否区分大小写取决于操作系统和lower_case_table_names配置：linux默认区分（值为0），windows/macos默认不区分（值为1或2）；运行时可通过select @@lower_case_table_names;查询，该值仅在重启后生效。

MySQL 表名到底区不区分大小写？

取决于操作系统和 lower_case_table_names 配置，不是 MySQL 自己决定的。Linux 默认区分，Windows 默认不区分，macOS（默认 HFS+ 或 APFS）行为类似 Windows，但底层仍是大小写敏感文件系统，MySQL 会强制转小写处理。

怎么查当前生效的 lower_case_table_names 值？

直接执行 SQL 查看运行时值，它反映的是 mysqld 启动时读取的配置，重启后才生效：

SELECT @@lower_case_table_names;

返回值只有三种可能：0（区分）、1（不区分，表名存为小写）、2（仅比较时不区分，存储保留原大小写）。生产环境几乎只用 0 或 1。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

改配置前必须知道的三个硬限制

• lower_case_table_names 是只读系统变量，不能 SET 修改，必须写进配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）的 [mysqld] 段里，然后重启 mysqld
• 从 0 改成 1 之前，必须确保所有表名已全小写，否则启动失败——MySQL 会尝试把大写表名对应的数据文件重命名为小写，但若同名小写文件已存在（比如 User 和 user 并存），就报错 Table 'xxx' doesn't exist
• 跨平台迁移时（比如从 Windows 备份恢复到 Linux），如果备份里混用了大小写表名，且目标设了 lower_case_table_names=1，恢复后可能只留下一个（最后被读到的那个），其余被静默忽略

开发和部署阶段最稳妥的做法

别赌系统默认值，统一按 lower_case_table_names=1 对待：所有建表语句、SQL 引用、ORM 映射、迁移脚本里的表名，全部用小写。这不是风格偏好，是避免在测试机（Windows/macOS）跑通、上线（Linux）就报错的最低成本方案。

真正麻烦的从来不是改配置，而是已有数据里藏着 User、user、USER 这种同音不同形的表——它们在 lower_case_table_names=1 下根本无法共存，删哪个都得人工核对业务逻辑。