索引字段大小写敏感吗
在做数据库查询或者搜索引擎优化时，经常会遇到一个问题：索引字段对大小写敏感吗？这个问题看似小，但在实际应用中影响不小。比如你在搜索用户“ZhangSan”时，输成“zhangsan”，系统能不能正确匹配，就和索引的大小写设置有关。
其实，索引是否区分大小写，并没有统一答案，它取决于你用的数据库类型、字符集设置，以及字段的排序规则（collation）。
MySQL 中的情况
以最常见的 MySQL 为例，默认情况下，如果你使用的是 utf8mb4_general_ci 或 utf8mb4_unicode_ci 这类结尾是 _ci 的排序规则，那它就是不区分大小写的（case-insensitive）。“ci” 就是 case insensitive 的缩写。这时候，建了索引的字段查 “ABC” 和 “abc” 是一样的。
但如果你用了 utf8mb4_bin 这种二进制排序规则，那就是严格区分大小写的。A 和 a 在二进制层面值不同，自然就被当成两个不同的值。
CREATE TABLE users (
name VARCHAR(50) COLLATE utf8mb4_bin,
INDEX idx_name (name)
);上面这个表，name 字段用的是 utf8mb4_bin，那么索引就会区分大小写。查 Name = 'Alice' 和 name = 'alice' 可能结果不同。
Elasticsearch 呢？
在搜索引擎 Elasticsearch 里，默认的文本字段会经过分词处理，而标准分词器（standard tokenizer）通常会把所有内容转成小写。也就是说，你存 “iPhone”，查 “IPHONE” 也能命中，因为索引时就已经统一小写了。
但如果你用了 keyword 类型并且关闭了小写转换，那就可能区分大小写。比如：
{
"mappings": {
"properties": {
"product_id": {
"type": "keyword",
"normalizer": "my_normalizer"
}
}
}
}这时候需要手动配置 normalizer 把输入统一处理，否则大小写可能影响匹配结果。
实际场景中的问题
想象一下，你做一个登录系统，用户名索引用的是默认设置，不区分大小写。用户注册了 "Admin"，别人尝试用 "admin" 登录，系统提示“用户已存在”或者直接登录成功，这体验就有点混乱。更稳妥的做法是在业务层统一转换，比如强制用户名存储时全转小写，避免歧义。
反过来，某些场景又需要区分大小写。比如密码字段，肯定不能因为大小写被忽略，那安全性就出问题了。不过密码一般不会建普通索引，而是通过哈希存储，这是另一个话题了。
所以，索引字段是否大小写敏感，关键看你怎么设。不能一概而论，得翻你的建表语句、查看 collation 或 mapping 配置才能确定。
下次遇到查询对不上，别急着查数据有没有错，先看看索引字段的排序规则是不是默默把大小写给“和谐”掉了。