MySQL默认的字符串比较为什么区分大小写？
MySQL的字符串比较行为取决于字段的COLLATION（排序规则），不是由字符集本身决定的。比如utf8mb4_bin是二进制排序规则，会逐字节比较，所以'A'和'a'不相等；而utf8mb4_general_ci或utf8mb4_0900_as_cs这类带_ci（case-insensitive）后缀的才不区分大小写。
常见错误是以为只要用了utf8mb4字符集就自动不区分大小写——其实不是，必须显式指定带_ci的排序规则。
- 建表时没指定
COLLATE，MySQL会用数据库默认排序规则，可能意外是_bin或_cs（case-sensitive） -
SHOW CREATE TABLE table_name能查到当前字段实际使用的COLLATE - 临时改比较行为可用
COLLATE utf8mb4_unicode_ci，但只影响当前语句，不改变存储逻辑
ALTER TABLE修改字段排序规则要小心什么？
直接ALTER TABLE ... MODIFY COLUMN加COLLATE看似简单，但容易踩坑：如果字段有索引，MySQL可能拒绝修改，报错ERROR 1267 (HY000): Illegal mix of collations；更隐蔽的是，修改后旧数据不会自动重编码，只是改变了比较逻辑，可能导致查询结果突变。
- 推荐做法：先备份，再用
ALTER TABLE t MODIFY COLUMN c VARCHAR(255) COLLATE utf8mb4_unicode_ci - 如果字段是主键或有唯一索引，需先
DROP INDEX，改完再重建 - 修改后执行
ANALYZE TABLE t更新统计信息，避免优化器误判 - 注意：
utf8mb4_unicode_ci在MySQL 8.0+已被utf8mb4_0900_ai_ci取代，后者对emoji和某些语言支持更好
WHERE条件里临时切换大小写敏感性怎么写？
不想改表结构时，可在查询中用COLLATE强制指定排序规则，比如WHERE name COLLATE utf8mb4_unicode_ci = 'John'。但要注意性能：如果name字段原排序规则是_bin，这个写法会让索引失效（因为隐式转换），除非你给该列加函数索引（MySQL 8.0+）。
- 安全写法：
WHERE name = 'John' COLLATE utf8mb4_unicode_ci（把COLLATE放在字面量侧，避免列被函数包裹） - 更稳妥的是用
LOWER()：WHERE LOWER(name) = LOWER('John')，但必须配合函数索引INDEX((LOWER(name)))才不慢 - 别用
BINARY反向操作来“变严格”，比如BINARY name = 'John'——这反而变成区分大小写了
ORDER BY排序结果大小写混乱怎么办？
即使字段是_ci排序规则，ORDER BY仍可能让'apple'排在'Apple'前面或后面，这不是bug，而是排序规则定义的行为。utf8mb4_unicode_ci按Unicode码点排序，小写字母整体靠后；而utf8mb4_0900_as_cs（accent-sensitive, case-insensitive）会把'a'和'A'视为等价后再排序，结果更符合直觉。
- 验证当前排序效果：
SELECT 'Apple', 'apple' ORDER BY 'Apple' COLLATE utf8mb4_unicode_ci, 'apple' COLLATE utf8mb4_unicode_ci - 若要严格按字母顺序忽略大小写，建表时用
COLLATE utf8mb4_0900_as_cs（MySQL 8.0+）或utf8mb4_general_ci（旧版本） - 线上环境改
COLLATE前，务必用SELECT ... ORDER BY对比新旧规则下的分页结果是否一致，否则前端分页会错乱
真正麻烦的不是语法怎么写，而是改排序规则会触发全表重建、锁表，且不同MySQL版本对_ci规则的实现细节有差异。上线前一定在从库上跑一遍ALTER，观察复制延迟和查询结果变化。
