推荐在SELECT中用UPPER/LOWER格式化输出，不改数据、不伤索引、不拖慢查询；WHERE/ORDER BY/GROUP BY中慎用，避免索引失效和性能损耗；入库时标准化才是根本解法。
直接在 SELECT 里用 UPPER() 或 LOWER() 就能安全统一输出格式，不改数据、不伤索引、不拖慢查询——这是唯一推荐的使用方式。
SELECT 中用 UPPER/LOWER 只是格式化，不碰原数据
它们返回新字符串，不影响表中存储值。适合导出、报表、前端展示等场景。
-
SELECT UPPER(name), LOWER(email) FROM users;→ 名字全大写、邮箱全小写显示，查的仍是原始字段，索引照常生效 - 对
NULL安全：UPPER(NULL)返回NULL，不会中断查询，但前端需处理空值显示 - 中文、emoji、数字、重音字符（如 é、ñ）不受影响，函数只动 ASCII 字母（A–Z / a–z）
- 别写
UPPER(*)—— 这会报错，UPPER是标量函数，只能作用于单个字符串表达式
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)));（MySQL）或CREATE INDEX idx_email_upper ON users (UPPER(email));（PostgreSQL） - SQLite 不支持函数索引，只能靠
COLLATE NOCASE或入库时就存小写 - 更稳妥做法：
INSERT INTO users (email) VALUES (LOWER(?));，查时直写WHERE email = 'joe@example.com'
ORDER BY 和 GROUP BY 中用函数会强制临时计算
ORDER BY LOWER(tag) 或 GROUP BY UPPER(status) 能出结果，但数据库得先算完所有行的函数值，再排序或分组——大数据量下内存和时间开销明显。
- 真正影响排序顺序的是 collation，不是函数。想严格按字典序排，用
ORDER BY tag COLLATE utf8mb4_bin比LOWER(tag)更快更可控 - 高频聚合建议加计算列：
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默认排最前
大小写统一这事，最容易被忽略的不是函数怎么写
而是你有没有在数据写入环节就做标准化——函数只是补救手段，不是设计替代品。入库时没约束，后续所有查询都得为大小写问题兜底，越拖越难收场。
