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