MySQL索引排序由字段定义的COLLATION决定，而非查询级设置；改字段COLLATION会改变B+树物理顺序，影响等价字符判定与索引使用；ORDER BY加COLLATE子句通常导致Using filesort。
MySQL 的 COLLATION 怎么影响索引排序？
索引排序行为不是由“单独设置的排序规则”决定的，而是由字段定义时的 COLLATION 直接绑定。你改字段的 COLLATE，索引就跟着按新规则排序；不改，哪怕查询里加 ORDER BY ... COLLATE xxx，索引也大概率用不上。
根本原因：B+ 树索引的物理顺序依赖字段值的二进制比较结果，而这个比较逻辑就来自 COLLATION。一旦字段 COLLATE 是 utf8mb4_0900_as_cs（大小写敏感、重音敏感），那索引里 “Apple” 和 “apple” 就是两个不同位置的键值；换成 utf8mb4_0900_ai_ci，它们就可能被归为等价，排序位置也会变。
-
COLLATION是字段属性，不是会话级或查询级开关 - 建表时没显式指定，会继承表默认
COLLATE；表没设，则继承数据库默认 - 修改字段
COLLATE会触发表重建（ALGORITHM=INPLACE在部分场景下可用，但非绝对）
怎么安全地改字段 COLLATION 并让索引生效？
直接 ALTER TABLE ... MODIFY COLUMN 改 COLLATE 很危险——如果字段上有索引，MySQL 会先删旧索引、再建新索引，期间该字段的查询可能全走全表扫描。更麻烦的是，如果字段是主键或唯一索引的一部分，还可能因重复值校验失败而报错（比如原 _ci 下不区分大小写的 “A” 和 “a”，在 _cs 下变成两个不同值，违反唯一约束）。
- 先查清当前值分布：
SELECT DISTINCT BINARY col_name FROM t WHERE col_name IS NOT NULL;看二进制是否真有重复 - 用
ALTER TABLE ... ALTER COLUMN col_name SET COLLATION xxx（8.0.30+）可避免重建，但仅限于兼容的 collation 之间（如utf8mb4_0900_ai_ci→utf8mb4_0900_as_cs） - 老版本必须
MODIFY COLUMN，建议在低峰期操作，并提前在测试库验证索引是否仍能用于ORDER BY和WHERE
为什么 ORDER BY col COLLATE utf8mb4_bin 不走索引？
因为优化器发现：索引是按字段定义的 COLLATION 排的，而你在查询里强行指定另一个 COLLATE，意味着需要对每个索引项做实时转换再比较，无法复用已有的有序结构。这时候 MySQL 通常放弃索引排序，改用文件排序（Using filesort）。
- 执行
EXPLAIN时看到Extra: Using filesort就是这个信号 - 除非字段本身
COLLATE就是utf8mb4_bin，否则加COLLATE子句基本等于放弃索引排序能力 - 想临时改变排序行为又想走索引？只能改字段定义，别指望查询层绕过
utf8mb4_unicode_ci 和 utf8mb4_0900_ai_ci 对索引有什么实际差别？
差别不在“能不能建索引”，而在“索引里怎么排”。比如字符 “ß”（德语eszett）：
-
utf8mb4_unicode_ci（旧）把它等价于 “ss”，排序时和 “ss” 混在一起 -
utf8mb4_0900_ai_ci（新）把它等价于 “ss”，但排序权重更精细，和 “ss” 的相对位置可能不同 - 这意味着：同一份数据，在两种 collation 下建的索引，叶子节点顺序不一致；跨 collation 查询
WHERE col = 'ss'可能命中率不同
升级到 8.0 默认 collation 后，如果业务依赖旧排序逻辑（比如前端分页靠 ORDER BY + LIMIT 稳定取数），很可能翻车——不是报错，而是分页错位、漏数据。
