upper/lower仅影响查询输出且不损伤索引，推荐用于select；where中裸用会导致索引失效，应配合函数索引或入库时标准化大小写。
SELECT里用UPPER/LOWER只改输出，不碰数据
直接写SELECT UPPER(name), LOWER(email) FROM users就能让结果里名字全大写、邮箱全小写，原表数据完全不动，索引照常生效，性能零损耗。这是唯一推荐的“安全用法”。UPPER(NULL)返回NULL，不报错但前端得自己处理空值显示；中文、emoji、数字原样透出，函数只动ASCII字母（a–z / A–Z）。
WHERE里裸用UPPER/LOWER大概率触发全表扫描
写WHERE UPPER(email) = 'JOE@EXAMPLE.COM'看似方便，实际会让email列上已有的索引失效——数据库没法把函数计算结果反向映射到B-Tree索引结构。百万级表上，响应可能从毫秒级拖到秒级。
- MySQL 8.0+ 和 PostgreSQL 支持函数索引：
CREATE INDEX idx_email_upper ON users (UPPER(email))（PostgreSQL）或CREATE INDEX idx_email_upper ON users ((UPPER(email)))（MySQL 8.0+） - SQLite 不支持函数索引，只能靠
COLLATE NOCASE或入库时就存小写 - 更稳妥的做法：入库时就用
INSERT INTO users (email) VALUES (LOWER(?))，查时直接WHERE email = 'joe@example.com'
ORDER BY和GROUP BY里用LOWER/UPPER会强制生成临时表
比如GROUP BY LOWER(tag)，数据库得先把所有tag值算一遍小写再分组，大数据量下内存和时间开销明显。排序同理：ORDER BY LOWER(name)不等于字典序，真正影响顺序的是collation。
- 想严格按ASCII顺序排，用
ORDER BY name COLLATE utf8mb4_bin比套函数更快更可控 - 高频聚合场景建议加计算列：
ALTER TABLE posts ADD COLUMN tag_lower VARCHAR(50) GENERATED ALWAYS AS (LOWER(tag)) STORED，再对tag_lower建普通索引 - PostgreSQL用户注意：
ORDER BY LOWER(name) NULLS LAST要显式声明NULLS LAST，否则NULL默认排最前
别指望UPPER/LOWER解决设计问题
大小写统一这件事，最容易被忽略的不是函数怎么写，而是你有没有在数据写入环节就做标准化——函数只是补救手段，不是设计替代品。入库时没约束，后续所有查询都得为大小写多一层转换、多一次索引失效风险、多一个collation兼容性坑。真正麻烦的从来不是SQL怎么写，而是表结构和写入逻辑有没有提前想清楚。
