MySQL 8.0索引“失效”主因是COLLATION不一致引发隐式转换，导致B+树索引无法使用；需用EXPLAIN与SHOW FULL COLUMNS交叉验证列、连接、JOIN字段的排序规则并统一为utf8mb4_0900_ai_ci等兼容规则。
MySQL 5.7 升级到 8.0 后索引“失效”，大概率不是索引没了，而是查询执行计划跳过了它——根本原因常出在字符集与排序规则（COLLATION）不一致引发的隐式转换。
为什么 utf8mb4_0900_ai_ci 会让索引突然不走？
MySQL 8.0 默认用 utf8mb4_0900_ai_ci，而 5.7 多为 utf8mb4_general_ci 或 latin1_swedish_ci。新排序规则更智能：它把罗马数字 Ⅰ、字母 I、甚至带重音的 í 都归一化为同一逻辑字符。这本身是增强，但会触发隐式转换：
- 当 WHERE 条件中传入的字符串字面量或参数的
COLLATION与索引列不一致时，MySQL 会自动转换一侧以完成比较 - 只要发生隐式转换，B+ 树索引就无法使用（优化器判定无法做范围扫描或等值查找）
- 例如：
WHERE name = 'testI'查询一个COLLATE utf8mb4_general_ci的列，在 8.0 下可能被转成CONVERT(name USING utf8mb4_0900_ai_ci) = 'testI'，索引直接失效
如何快速定位是不是 COLLATION 搞的鬼？
别猜，用 EXPLAIN + SHOW FULL COLUMNS 交叉验证：
- 查执行计划：
EXPLAIN SELECT * FROM t WHERE col = 'x';，重点看key是否为NULL，type是否退化为ALL - 查字段排序规则：
SHOW FULL COLUMNS FROM t LIKE 'col';，确认Collation值 - 查连接/客户端默认排序规则：
SELECT @@collation_connection, @@collation_database; - 如果三者不一致（比如列是
utf8mb4_general_ci，而连接是utf8mb4_0900_ai_ci），基本就是它了
修复必须对齐，不能只改一边
只改表、只改连接、或只加 COLLATE 临时修饰，都可能漏掉某条路径。稳妥做法是统一收敛：
- 改列定义（推荐）：
ALTER TABLE t MODIFY col VARCHAR(100) COLLATE utf8mb4_0900_ai_ci; - 显式指定条件排序规则（应急）：
WHERE col = 'x' COLLATE utf8mb4_0900_ai_ci - 修改数据库默认排序规则（影响新建对象）：
ALTER DATABASE db_name COLLATE = utf8mb4_0900_ai_ci; - 检查应用层参数绑定：JDBC 连接串要加
useUnicode=true&characterEncoding=utf8mb4&serverTimezone=UTC，否则驱动可能用错编码送参
最容易被忽略的其实是 JOIN 场景
单表查询看着正常，一 JOIN 就变慢——这是因为关联字段的 COLLATION 不一致，导致 MySQL 在 join buffer 中做全量转换。哪怕两个字段都是 utf8mb4，只要一个是 _general_ci、一个是 _0900_ai_ci，JOIN 条件就无法走索引。务必用 SHOW FULL COLUMNS 对比所有关联字段的 Collation 值，一个都不能差。
