mysql在linux下默认区分表名大小写，是因为lower_case_table_names默认值为0且ext4等文件系统本身区分大小写；该设置导致create table user与create table user被视为两个表，而select * from user会因大小写不匹配报错table 'db.user' doesn't exist。
MySQL在Linux下默认区分表名大小写，是因为lower_case_table_names默认值为0，且Linux文件系统（如ext4）本身区分大小写——这不是bug，是MySQL对底层特性的直接映射。
为什么lower_case_table_names=0在Linux上会出问题
这个值让MySQL完全按你写的大小写创建文件：User.frm和user.frm会被当作两个不同文件存到磁盘。但问题不在存储，而在使用：
- 应用代码里写
SELECT * FROM user，但建表语句是CREATE TABLE User→ 报错Table 'db.User' doesn't exist - ORM生成的SQL用小写表名，而迁移脚本或DBA手动建的表用了驼峰（如
UserProfile）→ 查询全挂 - 开发在macOS（默认
lower_case_table_names=2）能跑通，一上Linux服务器就炸 -
mysqldump导出时保留原始大小写，恢复时若目标库lower_case_table_names=1，但dump里写了CREATE TABLE OrderItem→ 导入后实际生成orderitem，但SQL里仍写OrderItem→ 后续查询失败
修改lower_case_table_names=1前必须做三件事
不能直接改配置重启——已有大写表名会导致启动失败，报Table 'xxx' doesn't exist，因为MySQL按小写路径去找文件，但磁盘上还是User.ibd。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 先用
mysqldump --all-databases --routines --triggers > full.sql导出全部数据（确保没加--skip-extended-insert，避免换行破坏表名大小写） - 停库后，手动把数据目录（如
/var/lib/mysql/your_db/）下所有.frm、.ibd、.MYD等文件名全转小写，例如User.frm→user.frm - 删掉
mysql系统库中tables、columns等表里残留的大写表名记录；更稳妥的是备份mysql库后清空整个mysql目录，再用mysqld --initialize重建权限库，最后导入
lower_case_table_names=2为什么比0还危险
它只在macOS上默认启用，表面看“建表保留大小写、查询忽略大小写”，实则埋雷：
-
CREATE TABLE A和CREATE TABLE a都能成功（APFS允许同名不同大小写），但第二个会静默覆盖第一个的数据文件 - InnoDB强制用小写存文件名，MyISAM可能保留原样 → 混用引擎时元数据和物理文件不一致
- 备份工具（如Percona XtraBackup）依赖文件系统路径，遇到
A.ibd和a.ibd共存会崩溃或跳过 - 一旦设为2，后续想切到1几乎不可能——没有可靠方式批量修正已存在的混合大小写表名
真正麻烦的不是改配置，而是改完之后所有SQL、ORM映射、运维脚本、监控指标里的表名都得同步改成小写。很多人只改了my.cnf就重启，结果发现应用连不上任何表——因为代码里还写着UserModel，而MySQL现在只认usermodel。
