索引失效主因是字符集或校验规则不一致导致隐式转换，使MySQL无法安全使用索引；需通过SHOW CREATE TABLE、SELECT @@collation_connection及EXPLAIN三步定位，并统一COLLATE而非用CONVERT函数。
为什么 WHERE 条件用上索引却还是全表扫描？
常见现象是：字段建了索引，EXPLAIN 显示 type=ref 或 range，但执行时间远超预期，SHOW PROFILE 或慢日志里看到大量 Copying to tmp table 或 Sorting result。根本原因常是字符集或校验规则不一致，导致 MySQL 无法安全使用索引做等值/范围比较，被迫转成隐式转换 + 全字段扫描。
典型触发场景：
-
WHERE col = 'abc'中col是utf8mb4_unicode_ci，而字符串字面量实际按连接默认校验规则（比如utf8mb4_0900_as_cs）解析 - 多表
JOIN时两边字段校验规则不同（如utf8mb4_general_civsutf8mb4_bin） - 函数包裹字段：
WHERE UPPER(col) = 'ABC'，但col的校验规则不支持大小写忽略的索引下推
查校验规则不一致的三步定位法
别猜，直接查。核心是确认「比较双方」的校验规则是否可兼容且能走索引。
第一步，查字段定义：
SHOW CREATE TABLE t1;
重点关注字段的 COLLATE 子句，例如 name VARCHAR(64) COLLATE utf8mb4_0900_as_cs。
第二步，查当前连接的默认校验规则：
SELECT @@collation_connection, @@character_set_client;
如果返回 utf8mb4_0900_as_cs 和 utf8mb4，说明客户端传入的字符串字面量会按此规则归一化 —— 若与字段规则不兼容（比如一个是 _as_cs，一个是 _unicode_ci），就可能失效。
第三步，查实际执行时的比较规则（最准）：
EXPLAIN FORMAT=TRADITIONAL SELECT * FROM t1 WHERE name = '测试';
看输出中的 possible_keys 和 key 是否一致；再加 AND 1=1 强制重写执行计划，观察 key_len 是否异常变大（比如从 128 跳到 255），这往往意味着 MySQL 在内部做了字符转换，无法精确估算索引长度。
CONVERT() 和 CASE 不是解药，COLLATE 才是开关
很多人想用 CONVERT(col USING utf8mb4) COLLATE utf8mb4_0900_as_cs 强制统一，但这是饮鸩止渴：函数包裹字段必然导致索引失效。真正该做的是让比较在「同一校验规则下原生进行」。
正确做法分两种：
- 显式指定字面量校验规则：
WHERE col COLLATE utf8mb4_0900_as_cs = 'abc' COLLATE utf8mb4_0900_as_cs—— 只要两边COLLATE完全一致，MySQL 就能跳过隐式转换，直连索引 - 统一表结构和连接配置：把字段、表、数据库、甚至
my.cnf里的collation-server全设成同一个现代校验规则（推荐utf8mb4_0900_as_cs），避免源头不一致
注意：utf8mb4_unicode_ci 在 8.0+ 已被标记为 deprecated，它对某些 emoji 和扩展汉字的排序行为不稳定，且与新校验规则混合时极易触发隐式转换。
JOIN 时校验规则不匹配的静默性能杀手
这是最容易被忽略的点：单表查询 EXPLAIN 看着没问题，一 JOIN 就变慢。因为 MySQL 要求 JOIN 条件两侧字段必须有「 coercibility 值相同」且「校验规则兼容」，否则自动选一个作为转换目标 —— 这个过程不仅消耗 CPU，还让索引失效。
检查方法：
SELECT
COLUMN_NAME, COLLATION_NAME,
COLLATION_NAME IS NULL AS is_implicit
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 't1' AND COLUMN_NAME IN ('a', 'b');如果发现 t1.a 是 utf8mb4_0900_as_cs，而 t2.b 是 utf8mb4_unicode_ci，那就必须改其中一个。优先改字段级 COLLATE（影响最小）：
ALTER TABLE t2 MODIFY b VARCHAR(64) COLLATE utf8mb4_0900_as_cs;
不要依赖 SET NAMES utf8mb4 COLLATE utf8mb4_0900_as_cs，它只影响后续语句的连接层解析，不改变字段定义，JOIN 时仍会触发转换。
校验规则不一致的问题不会报错，只会悄悄变慢。越晚发现，索引优化、缓存策略、读写分离做的越多，就越难回溯。
