Windows文件系统不区分大小写导致MySQL默认设lower_case_table_names=1，表名强制转小写存储；Linux迁入需mysqldump重导，强行设为0会导致启动失败或数据丢失。
Windows文件系统本身不区分大小写
MySQL在Windows上默认不区分表名大小写，根本原因不是MySQL自己“决定”的，而是它必须适配底层文件系统行为。Windows的NTFS/FAT文件系统对文件名不区分大小写，而MySQL的每个表（尤其是MyISAM和InnoDB）在磁盘上都对应一个或多个物理文件（如users.frm、users.ibd）。如果MySQL强行按大小写保存表名，但操作系统无法创建或区分Users.frm和users.frm，就会直接报错或覆盖文件。
lower_case_table_names=1是Windows默认配置
MySQL启动时会根据运行平台自动设置lower_case_table_names值。在Windows上，默认就是1，含义是：所有表名在存储和比较时都会被强制转为小写。这意味着：
-
CREATE TABLE UserTable(...)→ 实际存为usertable -
SELECT * FROM usertable、SELECT * FROM USERTABLE、SELECT * FROM Usertable全部能命中 - 即使你用大写建表，元数据里也只记小写，
information_schema.tables中table_name字段永远是小写
Linux环境迁移到Windows后突然查不到表？
这不是Windows“坏了”，而是配置不一致导致的元数据错位。典型场景：
- 表在Linux（
lower_case_table_names=0）上创建，表名含大写，比如UserOrder - 整个数据库目录直接拷贝到Windows，但MySQL仍按
lower_case_table_names=1启动 - MySQL尝试加载
userorder.frm，但实际文件是UserOrder.frm→ 报错Table 'db.UserOrder' doesn't exist - 即使手动改名文件，InnoDB字典里的表名仍是大写，仍会校验失败
这种情况下不能靠重命名文件修复，必须用mysqldump导出再导入，或提前统一设为lower_case_table_names=1并重建库。
想在Windows上强制区分大小写？小心踩坑
可以设lower_case_table_names=0，但风险极高：
- Windows文件系统不支持同名不同大小写的文件共存，MySQL可能无法启动，或启动后随机丢失表
- 已有数据库必须全部
DROP后重建，不能“切换参数重启”就生效 -
lower_case_table_names是只读变量，修改后必须彻底删除data目录并重新初始化实例 - 哪怕成功，应用里所有SQL必须严格匹配建表时的大小写，CI/CD、ORM生成语句稍有不慎就报错
真正需要区分大小写的场景（比如对接遗留系统），建议用COLLATE utf8mb4_bin控制字段值比较，而不是动表名规则——表名大小写问题本质是运维一致性问题，不是功能需求。
