UPPER和LOWER函数在WHERE子句中必须两端同时转换才有效，如WHERE UPPER(name) = UPPER('john')；单边转换无效且导致索引失效、全表扫描。
UPPER 和 LOWER 函数在 WHERE 子句中必须成对使用才有效
直接写 WHERE name = 'john' 永远不会匹配到数据库里存的 'John' 或 'JOHN'，大小写敏感是默认行为。想忽略大小写，得让左右两边都转成同一大小写形式再比——不能只转字段，也不能只转参数。
常见错误是只写 WHERE UPPER(name) = 'john'，这会查不到任何结果，因为 'john' 没转大写；正确做法是两边都转：
WHERE UPPER(name) = UPPER('john')
或者用小写版本：
WHERE LOWER(name) = LOWER('John')
- 推荐统一用
UPPER()：ASCII 字符下性能略好，且部分旧版 MySQL 对LOWER()在某些字符集下有边界问题 - 如果参数来自用户输入（比如表单），务必在拼 SQL 前就做一次
UPPER()处理，避免运行时重复计算 - 注意：Oracle 的
UPPER()对非 ASCII 字符（如带重音的法语字母）可能不完全等价于其他数据库，需验证实际数据表现
LIKE 查询中大小写忽略要额外加函数包裹
LIKE 本身不改变大小写逻辑，所以 WHERE name LIKE '%john%' 依然区分大小写。不能写成 UPPER(name) LIKE '%JOHN%' —— 这样虽然能查，但会导致索引失效（全表扫描）。
更稳妥的方式是把通配符也纳入函数处理范围：
WHERE UPPER(name) LIKE UPPER('%john%')
但要注意：
- 如果
name字段上有普通 B-tree 索引，UPPER(name)会跳过索引，除非你建了函数索引（如 PostgreSQL 的CREATE INDEX idx_name_upper ON users (UPPER(name))） - MySQL 8.0+ 支持函数索引，但需显式创建；MySQL 5.7 及之前不支持，此时建议改用
COLLATE utf8mb4_0900_as_cs（区分大小写）或utf8mb4_0900_as_ci（不区分）来定义字段排序规则，而非依赖函数 - SQL Server 用户可考虑用
COLLATE SQL_Latin1_General_CP1_CI_AS临时指定不区分大小写的比较
不同数据库对空值和 NULL 的处理差异明显
UPPER(NULL) 和 LOWER(NULL) 在所有主流数据库中都返回 NULL，但 WHERE UPPER(name) = UPPER('') 和 WHERE UPPER(name) = UPPER(NULL) 行为完全不同。
典型陷阱：
-
WHERE UPPER(name) = UPPER(NULL)永远为UNKNOWN（不是FALSE），结果就是查不到任何行，包括name IS NULL的记录 - 如果业务允许匹配空字符串或 NULL，得单独处理：
WHERE UPPER(name) = UPPER('john') OR (name IS NULL AND 'john' = '') - PostgreSQL 中还可配合
COALESCE(UPPER(name), '')统一空值为占位符，但要注意这会影响索引使用
替代方案：用 COLLATE 或 ILIKE 更简洁（但不通用）
不是所有场景都必须硬套 UPPER/LOWER。有些数据库提供原生不区分大小写的比较方式，性能更好、写法更干净：
- PostgreSQL：直接用
ILIKE——WHERE name ILIKE 'john%'
，支持通配符且能走索引（如果字段有合适的表达式索引） - MySQL：在字段定义时指定
COLLATE utf8mb4_unicode_ci，之后所有等值和LIKE默认就不区分大小写 - SQL Server：用
COLLATE Latin1_General_CI_AS临时修饰字段或字面量：WHERE name COLLATE Latin1_General_CI_AS = 'John'
- 注意：这些方法不可移植，换数据库就得重写；而
UPPER/LOWER是 SQL 标准函数，在 SQLite、MySQL、PostgreSQL、SQL Server、Oracle 中行为一致（除少数 Unicode 边界情况）
真正容易被忽略的是：当字段内容含混合 Unicode 字符（比如中文 + 英文 + emoji）时，UPPER() 在不同数据库中的实现可能不一致——Oracle 会按语言环境转换，而 SQLite 则只处理基本拉丁字母。这种情况下，别依赖函数做核心匹配逻辑，优先靠应用层标准化或专用全文检索引擎处理。
