MySQL升级后索引失效主因是新默认排序规则（如utf8mb4_0900_as_cs）与旧字段utf8mb4_unicode_ci不匹配，触发隐式转换致索引被弃用；须用SHOW FULL COLUMNS、SELECT @@collation_connection、SHOW CREATE TABLE逐层核对并统一COLLATE，ALTER时必须同时指定CHARACTER SET和COLLATE，且连接层需显式配置collation，JOIN字段COLLATION也须完全一致。
MySQL升级后索引失效，大概率不是索引丢了，而是utf8mb4_0900_as_cs或utf8mb4_0900_ai_ci这类新默认排序规则和旧字段的utf8mb4_unicode_ci不匹配，触发隐式转换，MySQL直接弃用索引。
查清哪一层的COLLATION实际在起作用
别靠经验猜，三处必须逐个确认：
-
SHOW FULL COLUMNS FROM table_name LIKE 'col_name';—— 看字段真实Collation值，注意它可能和表默认不同 -
SELECT @@collation_connection;—— 这个决定'abc'这种字面量按什么规则比较，升级后常变成utf8mb4_0900_as_cs -
SHOW CREATE TABLE table_name;—— 检查建表语句里是否显式写了COLLATE，还是依赖server默认
常见错配：字段是utf8mb4_unicode_ci，但@@collation_connection是utf8mb4_0900_as_cs，MySQL就会把字段值强制转成后者再比对，索引立刻失效。
ALTER TABLE时必须同时指定CHARACTER SET和COLLATE
只写CONVERT TO CHARACTER SET utf8mb4是危险操作——它会按当前server默认COLLATE覆盖，很可能把原utf8mb4_unicode_ci变成utf8mb4_0900_ai_ci，反而更不一致。
安全写法是显式锁定：
ALTER TABLE users MODIFY username VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：MODIFY会锁表；若不能停写，用CHANGE配合pt-online-schema-change。改完立刻SHOW CREATE TABLE验证，再跑EXPLAIN看key列是否出现索引名。
连接层collation不统一，改表白忙
应用连上后，@@collation_connection才是SQL中字符串字面量的“出生户口”。ORM或驱动没显式声明，MySQL就fallback到server默认值，极易错配。
- JDBC连接串加：
?useUnicode=true&characterEncoding=utf8mb4&collationConnection=utf8mb4_unicode_ci - PHP mysqli连接后执行：
mysqli_set_charset($conn, 'utf8mb4');+mysqli_query($conn, "SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci"); - 命令行客户端启动时加：
--default-character-set=utf8mb4 --collation-server=utf8mb4_unicode_ci
漏掉collation=这部分，前面所有表和字段改得再整齐，查询时仍可能触发转换。
JOIN场景下两边字段COLLATION必须完全一致
两张表关联字段哪怕都是utf8mb4，只要COLLATE不同（比如一边utf8mb4_unicode_ci，一边utf8mb4_0900_ai_ci），MySQL无法直接走索引做hash join或ref lookup。
验证方法：
SELECT character_set_name, collation_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_name IN ('t1', 't2') AND column_name = 'join_col';
修复原则：以主表或高频查询表的COLLATE为准，另一张表同步修改，且必须用MODIFY或CHANGE显式指定，不能只CONVERT。
真正容易被忽略的是：升级后ANALYZE TABLE可能没自动触发，旧统计信息会让优化器误判成本，导致本该走索引的查询选了全表扫描——所以EXPLAIN看到key为NULL时，先ANALYZE TABLE再排查字符集。
