linux文件系统区分大小写导致mysql表名敏感，windows则不区分；lower_case_table_names=0在linux默认且8.0后不可修改，windows设为0会失败；跨平台应统一用小写下划线命名。
Linux 和 Windows 的文件系统差异直接决定表名是否区分大小写
MySQL 本身不直接决定表名大小写，而是把表名映射为磁盘上的文件（如 user.frm、user.ibd），最终由底层文件系统解释。Linux 常用的 ext4、XFS 等文件系统严格区分文件名大小写；Windows 的 NTFS 默认不区分大小写（即 UserTable 和 usertable 指向同一文件）。MySQL 只是“顺从”了这个事实。
所以不是 MySQL “设计成这样”，而是它没能力绕过操作系统——你在 Linux 上执行 CREATE TABLE User()，MySQL 就真会在数据目录里建一个叫 User.frm 的文件；而 Windows 下哪怕你写 CREATE TABLE USER()，最终落地仍是 user.frm。
lower_case_table_names=0 在 Linux 是默认值，但不能动态修改
Linux 下 MySQL 启动时默认读取 lower_case_table_names=0，意味着：表名按原样存储、查询必须完全匹配大小写。这个值一旦 MySQL 实例初始化完成，就锁死了：
- MySQL 5.7：可修改配置后重启生效，但要求现有表名已符合新规则（比如全小写），否则启动失败或表不可见
- MySQL 8.0：初始化后禁止修改该参数，强行改会导致服务无法启动 —— 错误日志里会出现类似
Cannot change lower_case_table_names on the fly的提示
换句话说，想在已有 8.0 实例上开启不区分大小写？只能删掉 /var/lib/mysql 重装，而不是改个配置重启完事。
Windows 上设 lower_case_table_names=0 很可能失败
虽然文档说 lower_case_table_names=0 表示“大小写敏感”，但 Windows 文件系统不支持真正意义上的大小写区分。你硬要在 my.ini 里写 lower_case_table_names=0，MySQL 启动时会报错或静默降级为 1，并在错误日志中写入：
lower_case_table_names is set to 0, but the file system is case insensitive
这不是 bug，是 MySQL 主动拒绝违背操作系统能力的配置。所以别试图让 Windows 的 MySQL “变得敏感”——它做不到，也不该这么做。
跨平台部署最常踩的坑：SQL 脚本里混用大小写
开发在 Windows 写的 SQL 脚本，比如 SELECT * FROM UserProfile;，导出后直接导入 Linux 环境，就会报 Table 'UserProfile' doesn't exist。因为：
- Windows 导出时没强制转小写，脚本里保留了大驼峰
- Linux 上
lower_case_table_names=0，找不到UserProfile这个文件名 - 即使你后来把 Linux 配成
=1，旧表仍以原始大小写存在，不会自动重命名
真正可靠的解法不是靠运行时配置兜底，而是从源头统一：所有建表语句、SQL 查询、ORM 映射全部用小写字母加下划线（如 user_profile），连数据库名也小写。这比反复调参数更省事、更稳定。
