MySQL索引失效主因是字段、连接、函数返回值三者collation不一致引发隐式转换，破坏B+树可比性；需用SHOW FULL COLUMNS和@@collation_connection逐层核对并统一为utf8mb4_0900_as_cs等兼容规则。
不是默认排序规则本身让索引失效，而是它暴露了原有字段 collation 与函数/表达式/JOIN 字段之间隐式 collation 不匹配的问题，进而触发字符集隐式转换，破坏索引的可比性。
为什么 utf8mb4_0900_ai_ci 会让原本“能用”的索引突然不走
MySQL 8.0 将 collation_server 和新连接的 collation_connection 默认设为 utf8mb4_0900_ai_ci，但它并不改表结构——你老表里的字段还是 utf8mb4_general_ci。问题出在比较发生时：
- JOIN 或 WHERE 中两边字段 collation 不同（比如
t1.name COLLATE utf8mb4_general_civst2.name COLLATE utf8mb4_0900_ai_ci），MySQL 拒绝自动转换，直接报Illegal mix of collations，查询中断，根本轮不到走索引 - 更隐蔽的是：某些函数（如
FIND_IN_SET()、CONCAT()、子查询结果）返回值带“implicit” collation，其实际 collation 由上下文决定；一旦上下文是utf8mb4_0900_ai_ci，而字段是utf8mb4_general_ci，就构成混用 - 即使没报错，MySQL 也可能为对齐 collation，在内部对索引列做隐式转换（类似
CAST(name AS CHAR CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci)），导致无法命中 B+Tree 上原始值
哪些操作会因 collation 不一致真正绕过索引
以下场景中，即使 EXPLAIN 显示 key 非空，实际执行仍可能退化为全表扫描或 Handler_read_rnd_next 暴涨：
-
JOIN ON t1.col = t2.col，但两列 collation 不同（例如一个_general_ci，一个_0900_ai_ci） -
WHERE FIND_IN_SET(col, 'a,b,c')，其中col是utf8mb4_general_ci，而字符串字面量被解析为utf8mb4_0900_ai_ci -
ORDER BY col或GROUP BY col，若该列 collation 与连接默认 collation 冲突，排序阶段无法复用索引有序性 - 使用
utf8mb4_bin列与utf8mb4_0900_ai_ci列比较：binary 比较和 AI（accent-insensitive）比较逻辑互斥，无法对齐
怎么快速验证是不是 collation 导致索引失效
别猜，直接查真实字段定义和执行上下文：
- 用
SHOW FULL COLUMNS FROM table_name确认每列的Collation值，重点关注是否混用utf8mb4_general_ci/utf8mb4_0900_ai_ci/utf8mb4_bin - 在出问题的 SQL 前加
SELECT @@collation_connection, @@collation_database;，看当前会话实际生效的 collation - 对 JOIN 条件显式加
COLLATE强制统一：ON t1.name COLLATE utf8mb4_0900_ai_ci = t2.name COLLATE utf8mb4_0900_ai_ci，再EXPLAIN—— 如果这时 key 出现了，基本就是 collation 问题 - 检查慢日志中的
rows_examined：如果远大于结果集行数（比如查 10 行却扫 50 万行），且type=ALL或Extra含Using filesort/Range checked for each record，大概率是 collation 不匹配引发的隐式转换
最容易被忽略的点：collation 冲突不一定当场报错，它可能静默地让 MySQL 放弃使用索引，转而走临时表 + filesort，性能毛刺难定位。必须从字段定义层逐表摸清 collation，而不是只调 collation_server。
