MySQL表名大小写敏感由lower_case_table_names变量控制，取值0/1/2：0区分大小写（Linux默认），1不区分且强制转小写存储（Windows/macOS默认），2仅比较时不区分；初始化后不可安全修改，否则导致表找不到或启动失败。
MySQL 表名大小写敏感由 lower_case_table_names 决定
这个系统变量控制 MySQL 如何存储和比较数据库名、表名（不包括列名）。它不是“开关式”配置，而是取值为 0/1/2，且一旦初始化数据目录后就**不能安全修改**——强行改会导致表找不到、元数据损坏甚至启动失败。
常见错误现象：Table 'xxx.YYY' doesn't exist，但明明用 SHOW TABLES 能看到 yyy；或者应用在开发机（macOS）能运行，上线到 Linux 服务器就报错。
-
lower_case_table_names = 0：区分大小写（Linux 默认）。CREATE TABLE User和CREATE TABLE user是两个不同表 -
lower_case_table_names = 1：不区分大小写，所有表名强制转小写存储（Windows/macOS 默认）。SELECT * FROM User等价于SELECT * FROM user -
lower_case_table_names = 2：仅比较时不区分（macOS 兼容模式），但存储保留原大小写。实际极少用，且有兼容风险
新实例初始化前必须设对 lower_case_table_names
它只在 MySQL 初始化时（即首次启动 mysqld 且 data 目录为空）读取生效。运行中修改配置文件并重启，MySQL 会直接拒绝启动，并报错：Cannot change lower_case_table_names on the fly。
使用场景：Docker 部署、新测试环境搭建、重装生产库前。
- Linux 上想让表名不区分大小写？必须在
my.cnf的[mysqld]段落加lower_case_table_names = 1，然后用mysqld --initialize初始化空 data 目录 - 已存在的库？别硬改。要么导出 SQL（注意
CREATE TABLE语句里的表名大小写）、删库、改配置、重建、再导入；要么接受现状，统一用小写命名表 - Docker 用户容易踩的坑：镜像默认没设该参数，挂载的 volume 里已有旧 data，此时改配置也无效
Linux 下设 lower_case_table_names = 1 有隐性代价
表面上解决了大小写问题，但会带来两个真实影响：
- 性能微降：每次打开表都要做一次字符串小写转换，高并发下可测出毫秒级差异
- 无法混用大小写同名表：比如你建了
user，再建User会报Table 'User' already exists，即使你本意是两个表 - 某些 ORM 或迁移工具（如 Django
db_table、Laravel 迁移）若生成了大小写混合的表名，可能被静默转小写，导致后续引用出错
开发协作中最省事的做法
不折腾配置，统一约定表名全小写 + 下划线（user_profile），列名同样处理。这是绝大多数团队的实际选择。
为什么这么做比改配置更可靠？
- 避免跨平台（Mac/Linux/Windows）部署时因默认值不同引发问题
- Git 提交的 SQL 文件、ORM 映射、文档中的表名始终一致，不会出现
User和user混用 - DBA 或运维接手时不用查配置，一眼看懂命名逻辑
真要支持大小写敏感，唯一稳妥路径是全程用 Linux + lower_case_table_names = 0，且所有开发者严格遵守命名规范——但这要求太高，实际项目里几乎没人这么干。
