最通用做法是WHERE UPPER(name) = UPPER('alice')，因仅转一边会漏匹配；PostgreSQL宜用ILIKE，SQL Server/MySQL可优先试COLLATE提升索引利用率，跨库移植则坚定双UPPER()。
WHERE条件中用
做大小写统一转换
直接在JOIN或WHERE里对字段和值同时转大写，是最通用、兼容性最强的做法，适用于MySQL、PostgreSQL、SQL Server甚至SQLite。
常见错误是只转一边：
仍会漏掉小写存储的记录；必须两边都转：
。
MySQL默认不区分大小写（取决于列排序规则），但显式用
能确保行为一致，尤其跨库迁移时
PostgreSQL默认区分大小写，不用
或
会完全匹配失败
性能上，如果
字段没函数索引，
会导致全表扫描——生产环境建议补建函数索引，如 PostgreSQL：
用
指定不敏感排序规则（仅SQL Server / MySQL）
SQL Server和MySQL支持在查询时临时覆盖列的排序规则，比函数更轻量，且可能走原有索引（取决于collation是否支持索引查找）。
典型写法：
（SQL Server）或
（MySQL）。
表示case-insensitive，
表示accent-sensitive；MySQL中
已弃用，优先用
或
SQL Server里若原列是
（区分大小写）排序规则，不加
就无法匹配
和
注意：PostgreSQL不支持
用于WHERE等值比较的运行时切换，只能建表时指定或用
PostgreSQL专用：
替代
+
PostgreSQL没有
动态切换能力，但
是专为大小写不敏感设计的运算符，语义清晰、可读性好，且比
略快（内部优化）。
关联查询中直接用：
，无需额外函数包裹。
支持
通配符，和
行为一致，只是忽略大小写
不能用在索引字段上直接加速——除非建表达式索引：
，此时改用
反而能走索引
避免混用：
逻辑易错，统一风格更安全
JOIN时大小写不一致导致关联失败的真实场景
最常出问题的是多系统对接：比如用户表来自LDAP（全小写），而订单表里的
来自前端表单（首字母大写），直接
会大量丢失记录。
此时不能只修复一方数据，而应在SQL层做适配。推荐优先级：PostgreSQL用
；SQL Server/MySQL优先试
（索引友好）；其他场景或需要跨数据库移植时，坚定用
双裹。
别依赖数据库默认行为——MySQL的
排序规则就区分大小写，同一SQL在不同环境结果不同
如果关联字段是主键或有唯一约束，大小写不一致还可能触发“重复键”报错，比如
时
ORM框架（如Django、SQLAlchemy）生成的JOIN通常不自动处理大小写，得手动在filter或join条件里加转换
实际执行前，先用
检查是否存在纯大小写差异的重复值——这是最容易被忽略的数据质量盲点。
UPPER()WHERE name = UPPER('alice')WHERE UPPER(name) = UPPER('alice')UPPER()UPPER()ILIKEnameUPPER(name)CREATE INDEX idx_upper_name ON users (UPPER(name));COLLATEWHERE name COLLATE SQL_Latin1_General_CP1_CI_AS = 'Alice'WHERE name COLLATE utf8mb4_general_ci = 'Alice'_CI_ASutf8mb4_unicode_ciutf8mb4_0900_as_csutf8mb4_0900_ai_ci_CSCOLLATE'alice''Alice'COLLATEILIKEILIKE=LOWER()COLLATEILIKELOWER(col) = LOWER(val)ON u.name ILIKE p.owner_nameILIKE%LIKECREATE INDEX idx_owner_lower ON projects USING btree (LOWER(owner_name));LOWER(owner_name) = LOWER(?)WHERE name ILIKE 'Alice' OR name = 'BOB'user_idJOINILIKECOLLATEUPPER()utf8mb4_binINSERT ... SELECTSELECT UPPER(name), COUNT(*) FROM users GROUP BY UPPER(name)