MySQL表名大小写敏感完全由lower_case_table_names参数决定，该参数不可动态修改；设为0时严格区分大小写，设为1时强制转小写且需初始化前配置。
MySQL 表名大小写敏感由 lower_case_table_names 控制
MySQL 表名是否区分大小写，**完全取决于启动时的 lower_case_table_names 参数值**，且该参数不可动态修改——必须重启 mysqld 生效。它不是“开关式”配置，而是定义了表名在磁盘存储、SQL 解析、元数据查询三个环节的大小写行为规则。
lower_case_table_names=0：严格区分大小写（Linux 默认）
表名按 SQL 中写的原样存储（如 MyTable 存为 MyTable.frm），查询也必须完全匹配大小写：SELECT * FROM MyTable 和 SELECT * FROM mytable 被视为两个不同表。常见错误现象包括：
- 应用在开发环境（macOS/Windows）能运行，部署到 Linux 服务器后报错
Table 'xxx' doesn't exist -
SHOW TABLES列出的表名大小写与建表语句不一致（其实是文件系统真实名称） - mysqldump 恢复失败，因 dump 文件中表名大小写与目标库实际文件名不匹配
此模式下需确保所有 SQL、ORM 配置、备份脚本全程统一大小写，运维成本高，一般仅用于明确需要区分场景（如多租户按大小写隔离）。
lower_case_table_names=1：强制转小写（Windows/macOS 默认，推荐生产使用）
建表时无论写 CREATE TABLE UserLog 还是 CREATE TABLE userlog，最终都以小写形式存为 userlog.frm；后续所有查询（SELECT、DROP、ALTER）中的表名也自动转小写再匹配。关键点：
- 必须在初始化 MySQL 实例前设置，否则已存在的表名不会被重命名，可能导致元数据不一致
- 修改该值后重启，若之前有大写表名，
INFORMATION_SCHEMA.TABLES中仍显示原名，但实际无法通过原大小写访问 - 跨平台迁移安全：从 Windows 导出的 dump 在 Linux 上可直接 source（只要设为 1）
示例：设 lower_case_table_names=1 后执行 CREATE TABLE TestUser (id INT)，磁盘上生成 testuser.frm，之后用 SELECT * FROM TESTUSER 或 select * from testuser 均可成功。
修改前必须清空数据或重建实例
这是最容易被忽略的硬约束：lower_case_table_names 只在初始化数据库时生效。如果已有数据，直接改配置重启会导致：
- 服务启动失败（MySQL 检测到现有表名与新规则冲突）
- 部分表可查、部分报错（尤其混合大小写的旧表）
-
mysql_upgrade也无法修复表名映射问题
正确做法只有两个：① 停机导出所有数据（用 mysqldump --databases），删掉 datadir 下所有文件，修改配置后重新初始化并导入；② 在全新实例上设好参数再导入。别试图用 RENAME TABLE 手动改名——它不改变磁盘文件名，只是更新元数据，无法解决底层不一致。
