在MySQL里执行SELECT * FROM users WHERE name = 'admin';时，有些环境会查出Admin、ADMIN甚至aDmIn的记录，有些环境却一条都查不到。这个差异并不是MySQL版本造成的，而是字符集和排序规则在后台控制着字符串比较逻辑。

字符集决定了数据如何编码存储，排序规则则决定了字符如何比较和排序。排序规则名称中常见的_ci后缀代表case insensitive，即大小写不敏感；_cs后缀代表case sensitive，即大小写敏感；_bin后缀则按二进制值比较，对大小写严格区分。当表的排序规则采用_ci系列时，查询条件中的大小写差异会被自动忽略，这是很多开发者第一次遇到大小写问题时最先踩到的坑。

一、查看并理解MySQL默认的排序规则

在MySQL 8.0之前的版本中，utf8字符集的默认排序规则是utf8_general_ci，它对大小写不敏感。MySQL 8.0引入了更标准的utf8mb4_0900_ai_ci，同样不区分大小写。可以通过SHOW VARIABLES LIKE 'collation_server';查看服务器级别的默认排序规则，也可以在建库建表时单独指定。

例如下面这条建表语句没有显式指定排序规则，表会继承数据库的排序规则。如果数据库使用utf8mb4_general_ci，那么对name字段的查询就会忽略大小写。

CREATE TABLE users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50),
    email VARCHAR(100)
) DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

要确认某个列实际使用的排序规则，可以查询information_schema.COLUMNS。执行下面的SQL会显示各列对应的COLLATION_NAME，如果出现_ci或_ai_ci，就说明该列默认不区分大小写。

SELECT COLUMN_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_database'
  AND TABLE_NAME = 'users';

对于已有的表和列，如果不想修改表结构，可以只在查询语句中临时改变比较规则。MySQL提供了BINARY运算符和COLLATE子句两种方案，这两种方案虽然都能让查询区分大小写，但内部机制和对索引的影响完全不同。

二、用BINARY和COLLATE在查询中临时区分大小写

最直接的办法是在字段名前加上BINARY，它会把字符串当作二进制字节序列来比较，任何大小写差异都会导致不匹配。例如SELECT * FROM users WHERE BINARY name = 'admin';只会返回name列中值为小写admin的记录。

使用BINARY的好处是写法简单，不需要记住具体的排序规则名称。但缺点也很明显：BINARY会强制字段进行二进制转换，导致该列上的普通索引失效。如果表数据量很大，查询性能会明显下降，因为MySQL无法利用索引快速定位，必须扫描整张表逐行比较。

-- 使用BINARY临时区分大小写
SELECT id, name FROM users
WHERE BINARY name = 'admin';
-- 不使用索引，数据量大时执行效率低
EXPLAIN SELECT * FROM users WHERE BINARY name = 'admin';

另一种更优雅的方式是使用COLLATE子句，在查询时临时指定一个大小写敏感的排序规则，例如utf8mb4_bin或utf8mb4_0900_as_cs。这种方式理论上对索引的影响比BINARY小，因为MySQL可以在排序规则兼容的前提下利用索引，但实际效果仍然取决于字段本身的排序规则和优化器的判断。

-- 使用COLLATE临时切换为二进制排序规则
SELECT id, name FROM users
WHERE name COLLATE utf8mb4_bin = 'admin';
-- 使用COLLATE临时切换为大小写敏感排序规则
SELECT id, name FROM users
WHERE name COLLATE utf8mb4_0900_as_cs = 'admin';

如果查询中同时涉及多个字段，需要保证COLLATE子句的作用范围正确。比如WHERE name COLLATE utf8mb4_bin = email COLLATE utf8mb4_bin这种写法语法上会有歧义，最好分别对每个比较字段单独指定，或者直接在比较表达式的两边都加上COLLATE。

三、在建表和建列时指定大小写敏感的排序规则

对于长期需要区分大小写的业务字段，比如用户名、验证码、token等，最稳妥的做法是在表结构设计阶段就选择大小写敏感的排序规则。MySQL支持在列级别单独指定COLLATE，这样其他字段仍然可以使用大小写不敏感的默认排序规则，互不影响。

下面这张表把username列指定为utf8mb4_bin，它严格按照二进制值比较，Admin和admin会被视为两条完全不同的记录。同时nickname列继续使用utf8mb4_general_ci，保证昵称查询时大小写宽松。

CREATE TABLE account (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin,
    nickname VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci,
    UNIQUE KEY uk_username (username)
) DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

需要注意utf8mb4_bin虽然能严格区分大小写，但它也严格区分重音符号，比如a和á会被视为不同字符。如果业务上只需要区分大小写但希望忽略重音差异，可以考虑utf8mb4_0900_as_cs这类排序规则，不过该排序规则仅在MySQL 8.0及更高版本中可用，并且需要一定的存储空间和CPU开销。

已经存在的表如果发现排序规则选错了，可以使用ALTER TABLE修改列的排序规则。但修改操作会重建表数据，如果表数据量较大，建议在业务低峰期执行，并提前做好备份。

-- 将username列修改为大小写敏感排序规则
ALTER TABLE account
MODIFY username VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

四、大小写策略选择与查询优化建议

在实际项目中并不是所有字段都需要区分大小写。邮箱地址通常应该大小写不敏感，因为大多数邮件系统不区分邮箱前缀大小写；用户名则需要根据产品规则决定，有些网站允许用户注册Alice和alice两个不同账号，此时必须使用大小写敏感排序规则；而手机号、身份证号这类纯数字字段，大小写规则基本没有影响。

如果查询需要区分大小写，同时又要保证索引可用，最有效的做法是直接修改列排序规则为utf8mb4_bin。这样查询条件WHERE username = 'admin'天然就会区分大小写，不需要在SQL中额外写BINARY或COLLATE，索引也能正常工作。反之，如果使用BINARY作为临时方案，就要评估全表扫描带来的性能损耗，尤其是在百万级以上的表中。

另一个容易忽略的问题是排序规则的一致性。当JOIN两张表时，如果关联字段的排序规则不同（比如一张表是utf8mb4_general_ci，另一张是utf8mb4_bin），MySQL会抛出排序规则冲突错误。此时需要在JOIN条件中显式指定COLLATE，或者调整其中一张表的排序规则使其一致。

-- 排序规则冲突示例
SELECT a.id, b.id
FROM account a
JOIN users b ON a.username = b.name COLLATE utf8mb4_bin;

总结一下，MySQL查询区分大小写的核心在于排序规则。临时查询可以用BINARY或COLLATE快速解决，但要注意索引失效问题；长期稳定的方案是在建表建列时选择utf8mb4_bin等大小写敏感排序规则。无论采用哪种方式，都应该在表设计和SQL编写阶段就明确大小写策略，避免上线后因为数据比对不一致引发业务问题。