UPPER()和LOWER()需传字符串类型值，传NULL返回NULL而非空字符串；避免在WHERE中直接使用导致索引失效，应建函数索引或用大小写不敏感排序规则；务必配合TRIM处理空格，且注意跨库隐式转换差异。
UPPER 和 LOWER 函数怎么写才不报错
直接用 UPPER() 或 LOWER() 就行，但必须传入字符串类型值；传 NULL 会返回 NULL，不是空字符串——这点常被忽略，导致后续 WHERE 判断意外失效。
常见错误现象：SELECT UPPER(123) 在 PostgreSQL 报错，在 MySQL 可能隐式转成字符串但结果不可靠；SQL Server 会尝试转换但可能截断或出错。
- 只接受字符串表达式：字段名、字符串字面量（如
'hello'）、拼接结果（如CONCAT(first_name, ' ', last_name)） - 嵌套使用没问题：
UPPER(TRIM(name))，但注意函数执行顺序，TRIM要先于UPPER才有效 - 不同数据库对中文/emoji 支持一致，但大小写概念仅对 ASCII 字母有意义；
UPPER('你好')返回仍是'你好'
WHERE 条件里用 UPPER/LOWER 做模糊匹配的坑
想查邮箱不区分大小写？别直接写 WHERE UPPER(email) = UPPER('User@Example.COM')——这会让索引失效，尤其在大表上性能骤降。
真正该做的，是确保字段本身已建好函数索引（PostgreSQL/MySQL 8.0+ 支持），或者改用更安全的方式：
- MySQL 推荐用
COLLATE utf8mb4_0900_as_cs（大小写敏感）或默认的_ai_ci（不区分大小写），避免函数调用 - PostgreSQL 可建表达式索引：
CREATE INDEX idx_email_upper ON users (UPPER(email)) - SQL Server 建议用
COLLATE SQL_Latin1_General_CP1_CI_AS控制列级排序规则，而不是每次查都套函数
不同数据库对空格和 NULL 的处理差异
UPPER(NULL) 在所有主流数据库都返回 NULL，但空字符串 '' 行为一致；真正容易翻车的是带空格的字符串——比如前端传入 ' admin '，没 TRIM 直接转大写，匹配时仍会因空格失败。
- MySQL：
UPPER(' a ')→' A '（空格保留） - PostgreSQL / SQL Server 同样保留空格，不会自动清洗
- 实际业务中建议组合使用：
UPPER(TRIM(email))，且在 INSERT/UPDATE 时也做同样清洗，保持数据一致性 - 如果字段允许
NULL，WHERE 中记得加IS NOT NULL判断，否则UPPER(col) = 'X'会漏掉NULL行
需要批量更新字段为大写或小写时的操作要点
用 UPDATE 配合 UPPER() 或 LOWER() 很快，但要注意锁和日志体积——尤其是没加 WHERE 条件时，全表更新可能阻塞其他操作。
- 务必先测试：
SELECT id, name, UPPER(name) FROM users LIMIT 5 - 加上明确条件限制范围，比如
WHERE name IS NOT NULL AND name != UPPER(name) - MySQL 中若启用了
safe-updates模式，必须带键字段条件（如主键或有索引的字段）才能执行 - 更新后建议检查是否真生效：
SELECT COUNT(*) FROM users WHERE name != UPPER(name)
大小写转换看着简单，但实际踩坑多在隐式类型转换、索引失效和空格/NULL 处理上。别假设“函数跑通就完事”，得盯住执行计划和数据质量。
