MySQL表名和数据库名是否区分大小写由lower_case_table_names决定：0表示区分大小写（Linux默认），1表示不区分（Windows默认，自动转小写存储并匹配），2表示存储保留大小写但查询忽略（macOS常见）。
MySQL 表名和数据库名是否区分大小写，由 lower_case_table_names 决定；但查询时字符串是否区分大小写，跟这个参数完全无关。 它只管「表/库名怎么存、怎么找」，不管「WHERE name = 'Alice' 这种比较是否区分大小写」。搞混这两者，是踩坑最频繁的原因。
修改 lower_case_table_names 只影响表名和库名的解析方式
这个参数在 MySQL 启动时读取，运行中不可改，且修改后必须重启服务。它的取值逻辑很明确：
-
lower_case_table_names = 0：Linux 默认值，表名严格区分大小写（CREATE TABLE User和SELECT * FROM user是两个东西） -
lower_case_table_names = 1：Windows 默认值，所有表名自动转小写存储并统一按小写匹配（User、USER、user全指向同一个表） -
lower_case_table_names = 2：MacOS 常见，建表时保留大小写，但查询时忽略大小写（不推荐用于生产，行为易混淆）
注意：一旦设为 1，已有大写表名的数据库必须先重命名为全小写，否则重启后无法加载——MySQL 会尝试用小写路径去找文件，而原文件名是大写的，直接报错 Table doesn't exist。
让 WHERE 查询区分大小写，得靠字符集校对规则或 BINARY
比如你执行 SELECT * FROM users WHERE username = 'ADMIN' 却也命中了 'admin'，这不是 lower_case_table_names 的问题，而是字段的 COLLATION 是 utf8mb4_general_ci（_ci = case insensitive）。解决方法有两个：
- 临时强制：在条件前加
BINARY，如WHERE BINARY username = 'ADMIN'—— 简单直接，适合单条语句调试 - 永久生效：把字段的校对规则改成
utf8mb4_bin，例如：ALTER TABLE users MODIFY username VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
注意：改完后所有基于该字段的索引仍可用，但排序结果会变成字节序（A-Z-a-z），不是自然语言顺序
配置文件里加 lower_case_table_names=1 却启动失败？检查配置位置和权限
Linux 下 MySQL 不一定读 /etc/my.cnf，尤其用包管理器安装的版本（如 Ubuntu 的 mysql-server）默认走 /etc/mysql/mysql.conf.d/mysqld.cnf。错误地在 [client] 或 [mysql] 段下写 lower_case_table_names，会导致启动失败并报错 unknown variable。务必确认写在 [mysqld] 段内，且文件可被 mysqld 进程读取（常见坑：vim 保存时用了 root 权限但文件属主是普通用户，或 SELinux 限制）。
真正容易被忽略的是：表名大小写策略和字符串比较大小写策略，底层机制完全不同——前者是文件系统路径映射，后者是字符编码层面的二进制比对。改一个，另一个不会跟着变。线上环境调参前，先在测试库用真实表结构和数据验证兼容性，尤其是 lower_case_table_names 切换后，所有 SQL 脚本、ORM 映射、备份恢复流程都得同步检查。
