upper()做不区分大小写查询可行但性能差，因无法走索引；mysql 8.0+可建函数索引优化，否则建议用不区分大小写的collation或生成列加索引。
MySQL里用UPPER()做不区分大小写查询靠谱吗
靠谱，但只适合小数据量或临时查询。因为UPPER()会让字段无法走索引（除非你建了函数索引），查得越久，性能掉得越狠。
常见错误现象：SELECT * FROM users WHERE UPPER(name) = UPPER('Alice'); 在百万级表上可能从毫秒变秒级。
- 适用场景：WHERE条件值固定、字段无索引、或仅用于后台管理页的模糊搜索
- 别在高频接口或联表JOIN条件里用
UPPER()套字段，比如ON UPPER(a.name) = UPPER(b.name) - 如果真要用，MySQL 8.0+ 可以建函数索引：
CREATE INDEX idx_name_upper ON users (UPPER(name));
PostgreSQL怎么指定排序规则实现大小写不敏感
用COLLATE最直接，而且能走索引——前提是选对排序规则名。
例如：SELECT * FROM users WHERE name = 'alice' COLLATE "CITEXT"; 这样不行，"CITEXT"是扩展类型，不是排序规则。正确写法是先确保字段类型为citext，或者用COLLATE "und-x-icu"这类支持case-insensitive的ICU规则。
- 推荐方式：建表时就用
citext类型（需启用citext扩展），之后所有比较自动不区分大小写 - 临时生效：用
COLLATE "en-u-ks-level2"（level2 表示忽略大小写和重音） - 注意：不同PostgreSQL版本默认ICU支持状态不同，
SHOW lc_collate;看当前环境是否启用了ICU
SQL Server中COLLATE参数写错会报什么错
典型错误是Cannot resolve collation conflict，尤其在JOIN或UNION时两边字段排序规则不一致，SQL Server不肯自动转换。
比如users.name COLLATE SQL_Latin1_General_CP1_CI_AS和logs.user_name COLLATE Latin1_General_CI_AS直接JOIN，就会炸。
- CI表示Case-Insensitive，AS表示Accent-Sensitive；拼错如写成
CP1_CS_AS（CS=Case-Sensitive）就达不到目标 - 最稳写法：统一用
COLLATE DATABASE_DEFAULT，它继承当前数据库默认排序规则 - 建索引前确认字段排序规则，否则
WHERE name = 'X' COLLATE ...仍可能无法命中索引
SQLite里没COLLATE也没UPPER()索引？用LIKE凑合行不行
不行。LIKE 'abc%'在默认排序下仍是区分大小写的，除非显式声明COLLATE NOCASE。
SQLite的NOCASE是内建排序规则，轻量且高效，比UPPER()安全得多。
- 建表时指定：
name TEXT COLLATE NOCASE，之后所有=、ORDER BY、GROUP BY都自动不区分大小写 - 查询时临时加：
WHERE name = 'ABC' COLLATE NOCASE，但注意：只有等值比较才走索引，LIKE加COLLATE NOCASE仍可能全表扫 - 别信网上“
PRAGMA case_sensitive_like = OFF”，它只影响LIKE，不影响=，而且不改变索引行为
排序规则不是一设就灵，关键得看字段有没有索引、查询是否匹配索引使用条件。很多线上慢查，问题不在逻辑，而在COLLATE写对了却忘了字段本身没索引。
