UPPER()将字符串字母转大写、非字母保留，不修改原值；WHERE中需两边同转大写才能准确匹配，但无法走索引，建议MySQL 8.0+建函数索引或5.6+用生成列加索引，并注意字符集与collation影响。
MySQL 中用 UPPER() 函数做大小写转换
直接用 UPPER() 就行，它把字符串里每个字母转成大写，非字母字符原样保留。注意它不改变原字段值，只影响查询结果——想存大写得用 UPDATE 配合 UPPER()。
WHERE 条件里用 UPPER() 做不区分大小写的匹配
常见需求：查 email 字段等于某个邮箱，但用户输入可能是小写，而库里存的是大写或混合大小写。直接 WHERE email = 'ABC@EXAMPLE.COM' 会漏掉 abc@example.com 这种记录。
正确做法是两边都转大写再比：
SELECT * FROM users WHERE UPPER(email) = UPPER('abc@example.com');
- 别只转字段不转参数，否则大小写不一致还是匹配不上
- 这个写法无法走
email字段的索引，数据量大时会变慢 - 如果经常要不区分大小写查询，更稳妥的是建一个函数索引（MySQL 8.0+）：
CREATE INDEX idx_email_upper ON users (UPPER(email));
UPPER() 在不同字符集下的行为差异
UPPER() 的效果取决于字段的字符集和排序规则（collation）。比如 utf8mb4_unicode_ci 能正确处理带重音符号的拉丁字母，但 utf8mb4_bin 是二进制比较，UPPER() 对它没意义——因为 _bin 规则下大小写本身就是不同字节。
- 中文、数字、符号不受影响，始终原样返回
- 土耳其语等特殊语言需要对应 collation（如
utf8mb4_tr_0900_as_cs），否则i→I可能出错 - 查表确认当前字段 collation：
SHOW FULL COLUMNS FROM users LIKE 'name';看Collation列
容易忽略的性能和兼容性坑
在 ORDER BY 或 GROUP BY 里用 UPPER(name)，MySQL 会为每行实时计算，没法利用索引加速；老版本 MySQL（5.7 及之前）还不支持函数索引，只能靠冗余字段或应用层处理。
- 如果只是展示用，
SELECT UPPER(name) AS name_upper FROM ...安全无副作用 - 避免在 JOIN 条件里用
UPPER(a.col) = UPPER(b.col)，尤其大表关联时，性能下降明显 - MySQL 5.6 不支持表达式索引，真要高频不区分大小写查询，考虑加个生成列：
ALTER TABLE users ADD COLUMN email_upper VARCHAR(255) GENERATED ALWAYS AS (UPPER(email)) STORED;再给它建索引
大小写转换看着简单，实际卡在 collation、索引、版本限制上最多。别默认“转了就行”，先看字段定义，再想查询频次，最后选方案。
