能，但仅适用于字符串比较且需两端统一转换；若字段含BINARY或_cs collation可能报错或失效，且索引无法下推导致全表扫描。
WHERE条件里用UPPER/LOWER能解决大小写不匹配吗
能，但只适用于字符串值比较场景，且必须两端都统一转换。比如WHERE UPPER(name) = UPPER('Alice')会匹配'aLice'、'ALICE'，但前提是name字段本身不带BINARY或_cs collation——否则可能报错或行为异常。
常见错误是只转一边：WHERE UPPER(name) = 'alice'，这在SQL Server或PostgreSQL里会隐式触发类型转换，部分版本可能拒绝执行；MySQL虽容忍，但索引无法下推，全表扫描风险高。
- MySQL：若
name字段用utf8mb4_0900_as_cs，UPPER()仍有效，但性能不如直接用该collation做等值查询 - PostgreSQL：
UPPER()结果默认走text类型，若原字段是citext，反而会多一层隐式转换 - SQL Server：函数调用后无法利用原列上的索引，除非建函数索引（如
CREATE INDEX idx_upper_name ON t (UPPER(name))）
UPPER/LOWER在ORDER BY里为什么排序结果不对
因为UPPER()和LOWER()只改变字符大小写形态，不改变底层排序规则。比如ORDER BY LOWER(name)在MySQL用_ci collation时，仍按字典序排，但'a'和'A'会被视为相同前缀，实际顺序取决于原始字节值；在SQL Server里，若数据库collation是CI_AS，LOWER()后排序仍遵循重音敏感规则，café和cafe可能被分开。
真正影响排序的是collation本身，不是函数。想让排序严格按ASCII顺序，得用BINARY或_bin collation，例如ORDER BY name COLLATE utf8mb4_bin。
- 避免写
ORDER BY UPPER(name)来“强行统一”，这既慢又不可靠 - PostgreSQL中
ORDER BY name COLLATE "C"比UPPER()更接近ASCII排序 - 达梦数据库若
CASE_SENSITIVE=1，UPPER()对中文、数字无影响，但对英文字母生效，需确认业务是否真需要这种混合行为
哪些情况不该用UPPER/LOWER而该改collation
当查询高频、数据量大、且字段已有索引时，函数包装几乎必然导致索引失效。此时应优先调整collation，而不是在SQL里加函数。
- MySQL已有表：用
ALTER TABLE t MODIFY COLUMN name VARCHAR(50) COLLATE utf8mb4_0900_as_cs，注意锁表现象 - SQL Server列级：用
ALTER TABLE t ALTER COLUMN name VARCHAR(50) COLLATE SQL_Latin1_General_CP1_CS_AS - PostgreSQL字段：用
ALTER TABLE t ALTER COLUMN name TYPE TEXT COLLATE "en_US.utf8"（需确保系统支持该collation） - 达梦数据库：不能运行时改
CASE_SENSITIVE参数，必须重建库；但字段collation可用ALTER TABLE t MODIFY name VARCHAR(50) CASESENSITIVE（注意语法差异）
临时查一次？用WHERE name COLLATE utf8mb4_0900_as_cs = 'Test'比UPPER()更可能命中索引，尤其当索引本身也是该collation时。
UPPER/LOWER在JOIN和GROUP BY里容易踩的坑
JOIN条件里混用大小写转换极危险：比如ON UPPER(a.name) = UPPER(b.name)，若两边字段collation不同（如a是_ci、b是_cs），MySQL可能拒绝执行，PostgreSQL会报collation mismatch错误。
GROUP BY同理：GROUP BY LOWER(name)在SQL Server里会把'A'和'a'归为一组，但若后续SELECT里引用name原始值，结果不确定（非确定性聚合）。
- MySQL 8.0+允许
GROUP BY LOWER(name)，但SELECT name会报错，必须写SELECT LOWER(name) - PostgreSQL要求SELECT列表所有非聚合字段必须出现在GROUP BY中，所以
LOWER(name)必须完整出现在GROUP BY子句 - 达梦数据库对
GROUP BY UPPER(name)支持有限，建议先用子查询生成标准化字段再GROUP
最稳的方式是建计算列或物化视图预处理大小写，而不是每次查询都实时转换。
