MySQL字符串比较默认不区分大小写，根本原因是建表时未显式指定COLLATE，从而继承数据库默认排序规则（如MySQL 8.0+的utf8mb4_0900_ai_ci），其后缀_ci即表示case-insensitive；可通过SHOW FULL COLUMNS或SELECT COLLATION()直接查证字段实际校对规则。
MySQL字符串比较默认不区分大小写，根本原因不是MySQL“设计成这样”，而是你建表时没显式指定 COLLATE，它就用了数据库级默认排序规则——而这个默认值在 MySQL 8.0+ 通常是 utf8mb4_0900_ai_ci，后缀 _ci 就代表 case-insensitive。
怎么确认当前字段到底用的什么校对规则
别猜，直接查：
-
SHOW FULL COLUMNS FROM users LIKE 'name';→ 看输出里的Collation列 -
SELECT COLLATION(name) FROM users LIMIT 1;→ 返回具体规则名，比如utf8mb4_0900_ai_ci或utf8mb4_bin -
SHOW VARIABLES LIKE 'collation_database';→ 查数据库默认规则，新建字段若没指定，就继承它
BINARY、_bin、_cs 这些后缀到底啥区别
校对规则后缀决定比较逻辑，不是字符集本身管的：
-
_ci（如utf8mb4_unicode_ci）：大小写不敏感，'A'和'a'视为相等 -
_cs（如utf8mb4_0900_as_cs）：大小写敏感，但重音仍不敏感（é≈e） -
_bin（如utf8mb4_bin）：纯字节比较，'A'（ASCII 65）≠'a'（ASCII 97），连 emoji 都严格按编码比 -
BINARY关键字：临时把字段或值转成二进制比较，等价于加COLLATE utf8mb4_bin，但注意写法位置影响索引是否生效
为什么 ALTER TABLE MODIFY COLUMN 改 COLLATE 容易翻车
改字段校对规则看着简单，实际有隐藏陷阱：
- 如果该字段上有索引（尤其是唯一索引或主键），MySQL 可能直接报错
ERROR 1267 (HY000): Illegal mix of collations - 即使成功，旧数据不会重编码，只是比较逻辑变了——原来靠
_ci能查出多条的，换成_bin后可能突然只返回 1 条，业务逻辑悄悄崩了 - 改完必须执行
ANALYZE TABLE t;，否则优化器可能还按老统计信息选错执行计划 - 更稳妥的做法是：先
DROP INDEX，再MODIFY COLUMN ... COLLATE utf8mb4_bin，最后重建索引
真正容易被忽略的点是：COLLATE 是字段级设置，优先级高于表或数据库级；哪怕整个库设成 utf8mb4_bin，只要某个字段单独声明了 COLLATE utf8mb4_0900_ai_ci，它就还是不区分大小写——这种混用在迁移或多人协作时极难排查。
