UPPER 和 UCASE 在 MySQL 中完全等价，均为大小写转换函数，功能、性能、执行计划均一致；真正影响结果的是字符集与排序规则，而非函数名选择。
UPPER 和 UCASE 在 MySQL 中完全等价，选哪个都行，但别混用风格或误以为有功能差异。
UPPER 与 UCASE 是同一个函数的两个名字
MySQL 把 UCASE 当作 UPPER 的同义词实现，源码里直接 alias。执行 SELECT UPPER('hello'), UCASE('hello'); 结果一模一样，执行计划、性能、字符集处理逻辑也完全一致。
- 官方文档明确写 “
UCASE()is a synonym forUPPER()” - 在存储过程、触发器、视图定义里混用不会报错，但会降低可读性
- 某些 ORM（如旧版 Django）生成 SQL 时固定用
UPPER，硬写UCASE可能被静态检查工具标为不规范
真正影响转换结果的是字符集和排序规则
大小写转换不是简单查 ASCII 表，MySQL 依赖列的 collation。比如 utf8mb4_unicode_ci 和 utf8mb4_0900_as_cs 对德语 ß、土耳其语 İ 的处理完全不同。
- 对
utf8mb4_general_ci（已弃用），UPPER('ß')返回'ß'（不转），而utf8mb4_0900_as_cs下返回'SS' - 如果字段是
latin1_swedish_ci，UPPER('café')得到'CAFÉ'；但若字段是utf8mb4_bin，它仍按字节比较，UPPER仍能正确处理重音字符 - 安全做法：确保字段使用
utf8mb4字符集 + 区分大小写的排序规则（如utf8mb4_0900_as_cs），再用UPPER()
在 WHERE 或 ORDER BY 中用 UPPER 要小心索引失效
直接写 WHERE UPPER(name) = 'JOHN' 会让 name 列上的普通索引失效——MySQL 无法用索引快速定位“转成大写后等于 JOHN”的值。
- 替代方案：把条件值也转大写并确保列本身支持大小写不敏感匹配，例如建表时设
name VARCHAR(50) COLLATE utf8mb4_0900_as_cs，然后用WHERE name = 'JOHN'（此时比较自动按规则归一化） - 或者加函数索引：
CREATE INDEX idx_upper_name ON users ((UPPER(name)));（MySQL 8.0.13+ 支持） -
ORDER BY UPPER(name)同样无法利用name索引，需额外排序，大数据量时明显变慢
真正麻烦的不是函数选哪个，而是字符集配置是否一致、索引是否覆盖、以及业务是否真需要每次运行时做转换——很多时候，在应用层预处理或建计算列更可控。
