where子句中大小写不敏感查询需成对使用upper/lower函数，如lower(col)=lower(?)；注意索引失效、多语言locale差异及orm参数绑定陷阱。
UPPER/LOWER 函数在 WHERE 子句中必须成对使用
直接写 WHERE name = 'John' 是区分大小写的，数据库默认按字节比较。想让它不敏感，不能只转换字段或只转换参数——两边必须用同一套规则归一化。比如 WHERE UPPER(name) = UPPER('john') 才安全；如果写成 WHERE UPPER(name) = 'JOHN'，看似一样，但一旦参数来自用户输入（比如表单提交的 'john'），就容易漏匹配。
- MySQL、PostgreSQL、SQL Server 都支持
UPPER()和LOWER()，行为一致 - Oracle 中注意：空字符串会被转成
NULL，UPPER(NULL)还是NULL，会导致该行永远不匹配，需提前用COALESCE(name, '')处理 - SQLite 默认不区分大小写，但仅限于
LIKE；用=时仍需显式转换
用 LOWER 比 UPPER 更适合多语言场景
某些语言（如土耳其语）的大小写映射不是一一对应的：UPPER('i') 在土耳其区域设置下是 'İ'，而 LOWER('I') 是 'ı'（无点 i）。多数数据库默认用 C locale，但一旦服务器或连接设置了非英语 locale，UPPER 可能出意外。用 LOWER 稳定性略高，尤其处理用户昵称、邮箱等含国际字符的字段时。
- 推荐统一用
LOWER(col) = LOWER(?)，参数用占位符传入 - PostgreSQL 还可配合
citext扩展实现列级不敏感，但那是建表时决定的，不属于运行时函数方案 - 避免在索引字段上直接套函数——
LOWER(email)无法走email原始索引，要建函数索引：CREATE INDEX idx_users_lower_email ON users (LOWER(email));
LIKE 模糊搜索时大小写问题更隐蔽
LIKE 'john%' 在 MySQL 的 utf8mb4_0900_as_cs 排序规则下是区分大小写的，但很多人误以为它天然不敏感。错误写法：WHERE UPPER(name) LIKE UPPER('jo%')——这会强制全表扫描，因为 UPPER() 包裹了字段，索引失效；正确做法是先确保字段有函数索引，再保持写法简洁。
- 若只需前缀匹配，且字段已建
LOWER(name)索引，则写WHERE LOWER(name) LIKE 'john%' - PostgreSQL 支持
ILIKE，原生不区分大小写，但它是特有语法，跨数据库迁移时得重写 - SQL Server 用
COLLATE SQL_Latin1_General_CP1_CI_AS可临时指定不敏感排序规则，比函数更轻量，例如：WHERE name COLLATE SQL_Latin1_General_CP1_CI_AS LIKE 'john%'
参数绑定时别让 ORM 自动加引号破坏函数调用
有些 ORM（如旧版 Django ORM 或手写 MyBatis XML）会在参数占位符外自动加单引号，导致生成类似 WHERE UPPER(name) = 'UPPER(?)' 的 SQL——函数名被当字符串字面量，完全失效。必须确认最终执行的 SQL 是 UPPER(name) = UPPER('john')，而不是 UPPER(name) = 'UPPER(john)'。
- 用数据库日志或
EXPLAIN查看真实执行计划，确认是否走了索引 - Node.js + pg 里，参数用
$1占位，拼接进 SQL 字符串时别手动加引号 - Java + JDBC 中，
PreparedStatement的setString(1, "john")是安全的，函数包裹逻辑留在 SQL 字符串里即可
Seq Scan。
