upper/lower在where中未生效，根本原因是mysql默认collation大小写不敏感，导致name='john'已匹配'john'，无需函数；且函数会使索引失效，非ascii字符（中文、emoji等）不被转换。
UPPER 和 LOWER 函数在 WHERE 条件里为什么没生效？
常见现象是写 WHERE UPPER(name) = 'JOHN' 却查不到数据，或者明明有 'john' 却返回空。根本原因不是函数写错，而是 MySQL 默认的排序规则（collation）通常是大小写不敏感的（如 utf8mb4_0900_as_cs 是区分大小写，但 utf8mb4_0900_ai_ci 是不区分的），所以 name = 'john' 本身就匹配 'JOHN'，根本轮不到 UPPER 出场。
真正需要 UPPER/LOWER 的场景，是字段本身存储了混合大小写（比如用户输入未标准化），又想统一比对或展示——这时候得确认两点：
- 表字段的 collation 确实是大小写敏感型（查
SHOW CREATE TABLE tbl看 column 定义里的COLLATE） - WHERE 中用函数时，MySQL 可能无法使用索引（
UPPER(name)是表达式，索引失效），性能会掉；更稳妥的是把条件值转成同格式：WHERE name = UPPER('john')不行，应写WHERE name = 'JOHN'（前提是字段存的就是大写） - 如果必须函数化查询且字段无索引，考虑加函数索引：
CREATE INDEX idx_upper_name ON users ((UPPER(name)))（MySQL 8.0+ 支持）
中文、emoji 或带重音字符用 UPPER/LOWER 会出问题吗？
会。MySQL 的 UPPER() 和 LOWER() 只对 ASCII 字母（A-Z, a-z）做映射，对中文、日文、emoji、é/ñ/ü 等 Unicode 字符完全不做处理，原样返回。比如 UPPER('café') 返回 'café'，不是 'CAFÉ'；UPPER('你好') 还是 '你好'。
这不是 bug，是设计如此——MySQL 把大小写转换视为拉丁字母专属操作。如果你的应用需要国际化文本标准化（比如统一小写后查邮箱或用户名），别依赖这两个函数：
- 邮箱建议用应用层转小写（PHP 的
strtolower()、Python 的.lower()），再存进数据库 - 前端或 ORM 层做转换更可控，数据库只负责存储和精确匹配
- MySQL 8.0+ 虽支持部分 Unicode collation（如
utf8mb4_0900_as_cs），但依然不改变UPPER/LOWER对非 ASCII 字符的行为
UPDATE 语句里用 UPPER/LOWER 修改字段值要注意什么？
直接写 UPDATE users SET name = UPPER(name) 看似简单，但容易踩三个坑：
- 如果字段定义为
VARCHAR(20)，而原始值含多字节字符（如 emoji），UPPER 后长度不变，但若字段用了utf8mb3（已弃用）可能截断——务必确认字符集是utf8mb4 - 触发器或生成列（generated column）如果依赖该字段，函数更新可能引发隐式计算或循环更新，先检查表结构：
SHOW CREATE TABLE users - 没有
WHERE条件就全表更新，风险极高；至少加个过滤，比如WHERE name != UPPER(name)（注意：这个判断在大小写不敏感 collation 下永远为 false，得换方式，例如WHERE BINARY name != BINARY UPPER(name)）
替代方案：什么时候不该用 UPPER/LOWER，该用别的？
当目标是“忽略大小写比较”，用函数反而是下策。更高效、更安全的方式是靠 collation 本身：
- 建表时指定大小写不敏感 collation：
name VARCHAR(50) COLLATE utf8mb4_0900_ai_ci，之后WHERE name = 'JOHN'自动匹配 'john'、'John' - 临时改比较行为，用
COLLATE子句：WHERE name COLLATE utf8mb4_0900_ai_ci = 'JOHN' - 需要大小写敏感比对时，显式声明：
WHERE name COLLATE utf8mb4_0900_as_cs = 'JOHN' - 函数只适合“转换后展示”或“清洗入库”这类单向操作，别把它当成比较逻辑的基础设施
大小写处理真正的复杂点不在语法，而在字符集、collation、索引、应用层职责的耦合——漏掉其中一环，线上就可能查不到数据或慢得离谱。
