最近项目要做个迁移，使用了新的数据库，发现原来有些软件里自动生成的表，表名是大写，但是我们旧的项目里表名是小写，照样也跑的好好的；迁移的时候也没在意，但是迁移完毕后，发现系统不认了，数据库对表名大小写敏感

之前的项目都是规规矩矩的，该是啥是啥，没出过问题，所以对这块没有太多关注，今天用ai 整理了下关于MySQL 大小写敏感的相关设置说明

==================以下内容为ai生成==================

MySQL 大小写敏感完全指南：表名、字段名与数据值

一文搞懂 MySQL 中各种大小写敏感规则，告别混淆

📌 前言

很多 MySQL 初学者（甚至有些老手）对大小写敏感问题感到困惑：

为什么 WHERE name = 'John' 有时能匹配 JOHN，有时不能？
为什么表名有时区分大小写，有时不区分？
字段名写成大写和小写有区别吗？

本文将系统梳理 MySQL 中三个层面的大小写规则，帮你彻底理清这些概念。

🎯 核心概念：三个独立层面

MySQL 中的大小写敏感问题分为三个完全独立的层面：

层面	控制参数	默认行为
表名/数据库名	`lower_case_table_names`	取决于操作系统
字段名/列名	硬性规定（不可配置）	始终不区分大小写
字段内的数据值	字段的 Collation（校对规则）	通常不区分（`_ci`）

重要：这三个层面互不影响，需要分别理解！

1️⃣ 表名与数据库名的大小写

控制参数：`lower_case_table_names`

这个参数决定服务器如何处理表名和数据库名的大小写。

可选值及含义

值	行为	是否区分大小写	常见系统
`0`	按建表语句原样存储和比较	是（严格区分）	Linux/Unix
`1`	存储和比较时都转为小写	否（不区分）	Windows
`2`	按原样存储，比较时转小写	否（不区分）	macOS

查看当前设置

SHOW VARIABLES LIKE 'lower_case_table_names';

实际演示

假设 lower_case_table_names = 0（Linux 环境）：

-- 创建表（注意大小写）
CREATE TABLE UserList (id INT, name VARCHAR(50));
CREATE TABLE userlist (id INT, name VARCHAR(50));  -- 这是另一个表！

-- 查询时必须精确匹配大小写
SELECT * FROM UserList;     -- ✅ 正确
SELECT * FROM userlist;     -- ✅ 正确（访问另一个表）
SELECT * FROM USERLIST;     -- ❌ 报错：表不存在
SELECT * FROM Users;        -- ❌ 报错：表不存在

如果 lower_case_table_names = 1（Windows 环境）：

-- 大小写不敏感，以下都访问同一个表
SELECT * FROM UserList;     -- ✅
SELECT * FROM userlist;     -- ✅
SELECT * FROM USERLIST;     -- ✅

⚠️ 重要提醒

MySQL 8.0+ 中，实例创建后不能修改 lower_case_table_names，更改可能导致数据丢失！

最佳实践

-- 推荐：统一使用小写 + 下划线命名
CREATE TABLE user_list (     -- 表名全小写
    user_id INT,
    user_name VARCHAR(50)
);

2️⃣ 字段名与列名的大小写

硬性规则：永远不区分大小写

这是 MySQL 的硬性规定，无法通过任何配置或参数改变。

验证示例

CREATE TABLE test_user (
    UserId INT,           -- 字段名混合大小写
    FirstName VARCHAR(50)
);

-- 以下所有查询都能正常执行
SELECT UserId FROM test_user;      -- ✅
SELECT USERID FROM test_user;      -- ✅
SELECT userid FROM test_user;      -- ✅
SELECT uSeRiD FROM test_user;      -- ✅

-- 字段名可以随意混搭
SELECT FirstName, LASTNAME FROM test_user;  -- ✅ 正常运行

唯一需要注意的地方

虽然查询时字段名不区分大小写，但结果集的列名会按原始定义返回：

SELECT userid FROM test_user;
-- 结果集的列名仍然是 "UserId"（原始定义）

最佳实践

-- 虽然不区分大小写，但建议统一风格
CREATE TABLE users (
    user_id INT,          -- snake_case
    firstName VARCHAR(50) -- camelCase（不推荐混用）
);

-- 推荐统一使用 snake_case
CREATE TABLE users (
    user_id INT,
    first_name VARCHAR(50)
);

3️⃣ 字段内数据值的大小写

控制参数：Collation（校对规则）

这是最灵活、最容易混淆的层面。数据值的大小写行为由字段的校对规则决定。

常见校对规则

校对规则	是否区分大小写	是否区分重音	性能
`utf8mb4_general_ci`	否（`ci`=Case Insensitive）	否	快
`utf8mb4_unicode_ci`	否	完整Unicode支持	稍慢
`utf8mb4_0900_ai_ci`	否（`ai`=Accent Insensitive）	否	快（MySQL 8.0+默认）
`utf8mb4_bin`	是（二进制比较）	是	快
`utf8mb4_general_cs`	是（`cs`=Case Sensitive）	否	快

ci = Case Insensitive（不区分大小写）
cs = Case Sensitive（区分大小写）
bin = Binary（二进制比较，也区分大小写）

查看和设置校对规则

-- 查看字段的校对规则
SHOW FULL COLUMNS FROM users;

-- 建表时指定
CREATE TABLE users (
    username VARCHAR(50) COLLATE utf8mb4_general_ci,  -- 不区分
    password_hash VARCHAR(64) COLLATE utf8mb4_bin     -- 区分
);

-- 修改现有字段
ALTER TABLE users 
MODIFY username VARCHAR(50) COLLATE utf8mb4_bin;

-- 查询时临时指定
SELECT * FROM users 
WHERE username COLLATE utf8mb4_bin = 'Admin';

实际演示

CREATE TABLE test (
    name_ci VARCHAR(20) COLLATE utf8mb4_general_ci,
    name_bin VARCHAR(20) COLLATE utf8mb4_bin
);

INSERT INTO test VALUES ('Apple', 'Apple'), ('apple', 'apple');

-- 不区分大小写的字段
SELECT * FROM test WHERE name_ci = 'APPLE';   
-- 返回：Apple, apple（两条）

-- 区分大小写的字段
SELECT * FROM test WHERE name_bin = 'APPLE';  
-- 返回：空
SELECT * FROM test WHERE name_bin = 'Apple';  
-- 返回：Apple

影响的操作

操作	是否受 Collation 影响
`=` 比较	✅ 是
`LIKE`	✅ 是
`IN`	✅ 是
`DISTINCT`	✅ 是
`GROUP BY`	✅ 是
`ORDER BY`	✅ 是
唯一索引	✅ 是

选择建议

场景	推荐校对规则	原因
英文为主，追求性能	`utf8mb4_general_ci`	速度快
多语言，需要精确排序	`utf8mb4_unicode_ci`	Unicode标准
MySQL 8.0+ 新项目	`utf8mb4_0900_ai_ci`	默认，兼顾性能和准确性
密码/API Key 等敏感数据	`utf8mb4_bin`	精确匹配（但建议用哈希）
用户名/邮箱	`utf8mb4_general_ci`	用户体验好

⚠️ 性能提示

-- ✅ 可以使用索引
SELECT * FROM users WHERE username = 'admin' COLLATE utf8mb4_bin;

-- ❌ 无法使用索引（函数包裹）
SELECT * FROM users WHERE LOWER(username) = 'admin';

-- ✅ MySQL 8.0+ 可以创建函数索引
CREATE INDEX idx_username_lower ON users ((LOWER(username)));

📊 完整对比表

对象	是否区分大小写	由谁决定	能否改变
数据库名	取决于 `lower_case_table_names`	系统变量	实例创建后不可改
表名	取决于 `lower_case_table_names`	系统变量	实例创建后不可改
字段名	否（永远不区分）	MySQL硬性规定	不可改变
字段内的数据	取决于 Collation	字段校对规则	✅ 可以随时修改

🔧 实用技巧与常见问题

Q1：如何让查询区分大小写？

-- 方法1：使用 BINARY 关键字
SELECT * FROM users WHERE BINARY username = 'Admin';

-- 方法2：临时指定校对规则
SELECT * FROM users WHERE username COLLATE utf8mb4_bin = 'Admin';

-- 方法3：修改字段的校对规则（永久）
ALTER TABLE users MODIFY username VARCHAR(50) COLLATE utf8mb4_bin;

Q2：为什么表存在但查询报错”表不存在”？

-- 可能是表名大小写不匹配（Linux环境）
SHOW TABLES;  -- 显示 user_list
SELECT * FROM UserList;  -- 报错！应该是 user_list

Q3：如何让整个数据库的所有表统一大小写规则？

-- 设置数据库默认校对规则
CREATE DATABASE mydb COLLATE = utf8mb4_bin;

-- 或修改现有数据库
ALTER DATABASE mydb COLLATE = utf8mb4_bin;

Q4：跨平台迁移数据库要注意什么？

-- 1. 统一表名为小写
-- 2. 明确设置 lower_case_table_names
-- 3. 导出前检查大小写

-- 查看所有表名
SELECT TABLE_NAME FROM information_schema.TABLES 
WHERE TABLE_SCHEMA = 'mydb';

🎯 总结与建议

黄金法则

表名/数据库名：统一用小写 + 下划线，避免跨平台问题
字段名：虽然不区分大小写，也要统一风格（推荐 snake_case）
数据值：根据业务需求选择合适的 Collation
密码等敏感信息：在应用层用哈希比较，不要依赖数据库大小写

快速决策表

你的需求	怎么做
登录时不区分用户名大小写	使用 `_ci` 校对规则
订单号必须精确匹配	使用 `_bin` 校对规则
项目要跨 Linux/Windows 部署	表名全部小写
查询性能要求高	使用 `general_ci` 或 `0900_ai_ci`
需要德语等特殊语言支持	使用 `unicode_ci` 或 `0900_ai_ci`

一句话记忆

表名看系统，字段名不区分，数据看校对规则 —— 三者独立，互不影响！

📚 参考资源

希望这篇文章能帮你彻底理清 MySQL 的大小写问题！如有疑问，欢迎留言讨论。

MySQL 大小写敏感完全指南：表名、字段名与数据值

MySQL 大小写敏感完全指南：表名、字段名与数据值

📌 前言

🎯 核心概念：三个独立层面

1️⃣ 表名与数据库名的大小写

控制参数：lower_case_table_names

可选值及含义

查看当前设置

实际演示

⚠️ 重要提醒

最佳实践

2️⃣ 字段名与列名的大小写

硬性规则：永远不区分大小写

验证示例

唯一需要注意的地方

最佳实践

3️⃣ 字段内数据值的大小写

控制参数：Collation（校对规则）

常见校对规则

查看和设置校对规则

实际演示

影响的操作

选择建议

⚠️ 性能提示

📊 完整对比表

🔧 实用技巧与常见问题

Q1：如何让查询区分大小写？

Q2：为什么表存在但查询报错”表不存在”？

Q3：如何让整个数据库的所有表统一大小写规则？

Q4：跨平台迁移数据库要注意什么？

🎯 总结与建议

黄金法则

快速决策表

一句话记忆

📚 参考资源

控制参数：`lower_case_table_names`