在数据库或搜索引擎中设置索引时，很多人会遇到一个问题：索引字段对大小写敏感吗？这看似是个小细节，但实际使用中可能带来意想不到的问题。比如你在查用户信息时，输入“ZhangSan”没搜到结果，换成“zhangsan”却出来了，这就跟大小写是否敏感有关。
不同系统处理方式不一样
这个问题没有统一答案，关键看用的是什么系统。拿常见的 MySQL 来说，默认情况下，字符型索引字段（如 VARCHAR）在使用 utf8_general_ci 或类似的排序规则时是不区分大小写的。ci 就是 case insensitive 的缩写，意思是“不区分大小写”。这时候你建了索引，查 “ABC” 和 “abc” 效果一样。
SELECT * FROM users WHERE username = 'Admin';
-- 如果 username 字段用的是 _ci 排序规则，那么 Admin、admin、ADMIN 都能命中但如果你改用 utf8_bin 这种二进制排序规则，情况就变了。它会逐字节比较，这时候“A”和“a”就是两个不同的字符，索引也就变成大小写敏感的了。
其他数据库也有类似机制
MongoDB 默认也是区分大小写的。如果你往集合里插了一条 {"name": "Tom"}，然后用 {"name": "tom"} 去查，是查不到的，哪怕你加了索引也没用。除非你自己在查询时用正则忽略大小写，或者提前把数据统一转成小写存储。
db.users.find({"name": /tom/i });
// 加 i 表示忽略大小写Elasticsearch 的 keyword 类型默认也是区分大小写的。想模糊匹配就得借助 lowercase 分析器，或者在字段映射里设置 normalizer 来统一处理。
实际应用建议
多数业务场景下，用户名、邮箱这类字段最好别让大小写影响搜索结果。你可以建索引前先把值转为全小写，或者选一个不区分大小写的排序方式。这样用户体验更顺，不会因为输错大小写就登录不了账号。
反过来，某些安全相关场景可能需要精确匹配，比如密码哈希前的盐值、API 密钥等，这些就必须保持大小写敏感，否则容易出漏洞。
所以问题不在索引本身，而在字段类型和排序规则的搭配。搞清楚你用的技术栈怎么处理字符比较，比死记结论更重要。