MySQL 大小写敏感性配置与迁移指南

1. 概述

MySQL 的大小写敏感性主要涉及两个维度：

元数据（Metadata）：指数据库名、表名、别名等。
数据内容（Data Content）：指字段中存储的字符串值（如 'Admin' vs 'admin'）。

本指南旨在解决开发环境（通常为 Windows，不敏感）与生产环境（通常为 Linux，敏感）配置不一致导致的问题，并提供安全的迁移与排查方案。

2. 现状诊断：如何检查敏感性

在执行任何变更前，必须确认当前的配置状态。

2.1 检查表名/库名敏感性

此配置由系统参数 lower_case_table_names 控制。

SQL 语句：

SHOW VARIABLES LIKE 'lower_case_table_names';

参数值说明：

值	含义	行为表现	常见平台默认值
0	敏感	存储为给定的大小写，比较时区分大小写。	Linux / Unix
1	不敏感	存储为小写，比较时不区分大小写。	Windows
2	不敏感	存储为给定的大小写，比较时转换为小写。	macOS

2.2 检查数据内容敏感性

数据内容的比较取决于字符集排序规则（Collation）。

SQL 语句：

-- 查看当前数据库默认规则
SHOW VARIABLES LIKE '%collation%';

-- 快速测试当前环境比较逻辑（1=不敏感，0=敏感）
SELECT 'A' = 'a';

常见后缀含义：

_ci (Case Insensitive)：大小写不敏感（默认，如 utf8mb4_general_ci）。
_bin (Binary) / _cs (Case Sensitive)：大小写敏感。

3. 核心问题：从“敏感”迁移到“不敏感”

场景描述

当前环境 lower_case_table_names = 0（区分大小写），需要更改为 1（不区分大小写）。

⚠️ 风险预警

全局生效：该参数是 Global 级别的，无法仅对某个特定数据库生效。
MySQL 8.0 限制：在 MySQL 8.0+ 版本中，该参数只能在初始化（Initialize）数据目录时设置。一旦初始化完成，修改配置文件重启将报错。
数据损坏风险：直接修改配置重启（在旧版本中）会导致 MySQL 强制用小写查找表文件，导致“Table not found”甚至文件索引损坏。

解决方案 A：全量重建（推荐，最标准）

适用于必须更改数据库配置，且能接受停机维护的场景。

步骤：

全量备份：使用 mysqldump 导出所有数据库（包括存储过程、触发器）。
```
mysqldump -u root -p --all-databases --routines --events > dump_all.sql
```
停止服务：停止 MySQL 服务。
移除旧数据：备份并移走原 datadir（如 /var/lib/mysql）。
```
mv /var/lib/mysql /var/lib/mysql_backup
```
修改配置：编辑 /etc/my.cnf。
```
[mysqld]
lower_case_table_names = 1
```

重新初始化：

mkdir /var/lib/mysql
chown mysql:mysql /var/lib/mysql
mysqld --initialize --user=mysql --datadir=/var/lib/mysql

恢复数据：启动服务并导入 SQL 文件。导入过程中，MySQL 会自动将所有大写表名转换为小写存储。

解决方案 B：表名规范化（妥协方案）

适用于无法重新初始化实例，或者只有个别库需要适配代码的场景。

核心思路：不改 MySQL 配置，改表名。将表名手动重命名为全小写，以适应 lower_case_table_names=0 的环境。

找出大写表：

SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = '你的库名' AND TABLE_NAME REGEXP BINARY '[A-Z]';

批量重命名：
```
RENAME TABLE UserInfo TO userinfo;
```
规范代码：确保业务代码中的 SQL 语句全部使用小写表名。

解决方案 C：独立实例隔离

适用于无法修改现有实例配置（影响其他库），且业务代码无法修改（强制依赖不敏感环境）的场景。

步骤：

使用 Docker 或新服务器部署一个新的 MySQL 实例。
配置新实例为 lower_case_table_names = 1。
仅将目标数据库迁移至该新实例。
修改应用程序的数据库连接地址。

4. 常见误区解答

Q: 我可以只导出一个库，改完配置后再导回去吗？
A: 不可以。
因为修改配置需要重新初始化（清空）整个 MySQL 实例。如果你只导出了一个库，重新初始化后，未导出的其他数据库将永久丢失。必须进行全量导出。

Q: 我可以在 Linux 上直接改配置文件然后重启吗？
A: 严禁操作。
这会导致严重的元数据不一致。MySQL 试图以小写访问磁盘上的大写文件，会报表不存在错误。

Q: 如何在查询时临时强制区分大小写？
A: 使用 BINARY 关键字。

SELECT * FROM users WHERE BINARY username = 'Admin';

5. 最佳实践建议

统一开发规范：
- 建表规范：无论在 Windows 还是 Linux，表名、字段名一律强制使用全小写，单词之间用下划线分隔（snake_case）。
- SQL 规范：业务代码中的 SQL 语句，表名也一律使用小写。
环境对齐：
- 建议将开发环境的 Docker 或本地 MySQL 配置调整为 lower_case_table_names = 0（Linux 默认值），以便在开发阶段就暴露大小写问题，而不是等到上线才发现。
ORM 框架注意：
- 使用 Hibernate、MyBatis 等框架时，注意实体类上的 @Table(name="...") 注解，确保与数据库实际表名大小写一致。