必须两端统一用lower()转换，如where lower(name) = lower('alice')，单边转换会漏匹配；需同步建函数索引或改collation以防全表扫描。
直接结论：别依赖数据库默认行为，优先用 LOWER() 两端统一转换，但必须同步解决索引失效问题。
WHERE 中用 LOWER() 必须两边都转
只转字段或只转值都会漏匹配。比如 WHERE LOWER(name) = 'alice' 仍区分大小写——右边是原始字符串，没被转换；WHERE name = LOWER('Alice') 同样无效，因为左边还是原始存储值。
- 正确写法只有：
WHERE LOWER(name) = LOWER('Alice')或WHERE UPPER(name) = UPPER('Alice') - 推荐统一用
LOWER()，部分数据库（如 PostgreSQL）对 Unicode 小写转换更稳定；UPPER()在土耳其语环境可能把 ‘i’ 转成 ‘İ’，引发意外不匹配 - 如果关键词来自用户输入，建议在应用层先做一次
toLowerCase()，SQL 里只转字段，避免函数重复调用影响可读性
LIKE 模糊搜索时大小写处理不能省略
LIKE 的大小写敏感性完全由字段的 collation 决定，不是语法自带特性。哪怕 MySQL 默认用 utf8mb4_0900_ai_ci，一旦字段被显式设为 _bin 或 _cs 规则（如 utf8mb4_bin），LIKE '%abc%' 就立刻变严格匹配。
- 安全写法始终是：
WHERE LOWER(name) LIKE LOWER('%il%')—— 通配符%和_本身不受LOWER()影响，不会出错 - 错误写法：
WHERE name LIKE '%il%'，看似简洁，但实际行为取决于当前会话、复制配置、甚至从库 collation，极易漂移 - 注意：PostgreSQL 没有通用等价于
ILIKE的跨库方案，硬切ILIKE会锁死数据库选型
索引失效是真实性能瓶颈，不是理论风险
只要 WHERE 里出现 LOWER(name)，MySQL、PostgreSQL、SQL Server 都会跳过普通 B-tree 索引，触发全表扫描。10 万行可能就明显卡顿，不是“稍微慢一点”。
- MySQL 8.0+ 可建函数索引：
CREATE INDEX idx_name_lower ON users ((LOWER(name)))—— 注意双括号写法，不是(LOWER(name))字段名 - PostgreSQL / MySQL 5.7+ 支持生成列：
name_lower TEXT GENERATED ALWAYS AS (LOWER(name)) STORED，再对name_lower建普通索引 - 更彻底的做法：写入时就存标准化值，比如新增
email_ci字段存LOWER(email)，业务查询走该字段 + 索引，避免运行时计算
什么时候该换 collation 而不是加函数
高频查询 + 大数据量 + 字段已有索引 → 函数包装几乎必然导致索引失效，这时改 collation 是更优解。
- MySQL：把字段 collation 改成
utf8mb4_0900_as_cs（大小写敏感）或utf8mb4_0900_as_ci（不敏感），ALTER TABLE t MODIFY name VARCHAR(100) COLLATE utf8mb4_0900_as_ci - SQL Server：临时生效用
WHERE name COLLATE Chinese_PRC_CS_AI = 'User'；永久修改用ALTER COLUMN指定CS_AI规则 - 关键提醒：改 collation 可能重建索引、锁表，生产环境务必在低峰期操作；且需确认上下游系统（如 ORM、ETL 工具）是否兼容新规则
真正麻烦的不是写对那条 SQL，而是 collation 配置、索引策略、写入逻辑三者没对齐。比如字段用了 _ci 规则，但应用层又在 SQL 里套 LOWER()，既冗余又掩盖了真实一致性风险。
