upper()和lower()函数仅用于select输出格式化，安全高效且不影响索引；where、order by、group by中慎用，否则易致性能下降，推荐入库时即统一大小写。
直接在 SELECT 里用 UPPER() 或 LOWER() 就能统一输出大小写，不改数据、不依赖索引、无性能风险——这是唯一安全且推荐的使用场景。
SELECT 中用 UPPER/LOWER 只是格式化输出，不会影响查询性能
这类写法纯粹作用于结果集渲染，数据库执行计划不受干扰，原字段索引照常生效。
-
SELECT UPPER(name), LOWER(email) FROM users;→ 名字全大写、邮箱全小写展示，查的是原始值，走索引没问题 - 对
NULL安全：UPPER(NULL)返回NULL，不会中断查询，但前端需处理空值显示 - 中文、emoji、数字不变形：
UPPER('你好123') → '你好123'，函数只动 ASCII 字母（A–Z / a–z） - 避免嵌套错误：想清洗再转大写，得写成
UPPER(TRIM(name))，而不是TRIM(UPPER(name))——后者可能保留首尾空格里的大写字母
WHERE 条件里别裸用 UPPER/LOWER，否则大概率触发全表扫描
写 WHERE UPPER(email) = 'JOE@EXAMPLE.COM' 看似方便，实际让 email 列上已有的索引失效，尤其在百万级表上响应会从毫秒变秒级。
- 根本原因：索引存的是原始值，数据库无法把函数计算结果反向映射到索引结构
- MySQL 8.0+ 和 PostgreSQL 支持函数索引，但必须显式创建：
CREATE INDEX idx_email_upper ON users (UPPER(email)); - 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 值算一遍小写，再分组——大数据量下内存和时间开销明显。
- 真正影响排序顺序的是 collation，不是函数。想严格按字典序排，用
ORDER BY tag COLLATE utf8mb4_bin比ORDER BY 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默认排最前，可能打乱业务预期
大小写统一这件事，最容易被忽略的不是函数怎么写，而是你有没有在数据写入环节就做标准化——函数只是补救手段，不是设计替代品。
