索引失效主因是where中对索引列使用函数或隐式类型转换，以及join/where字段字符集或排序规则不一致；应确保查询值类型与索引列严格一致，并统一字符集和collation。
WHERE 条件里对索引列做函数或隐式转换，索引就失效了
MySQL 在执行查询时，如果在 WHERE 子句中对索引列使用函数（比如 UPPER()、DATE()），或者让该列参与隐式类型转换（比如字符串索引列跟数字比较），优化器大概率会放弃走索引，转为全表扫描。
常见错误现象：EXPLAIN 显示 type=ALL 或 key=NULL，哪怕字段明明建了索引；QPS 突然下跌、慢查询日志里反复出现同一类语句。
- 字符串索引列（如
user_id VARCHAR(32)）写成WHERE user_id = 123→ MySQL 会把每行user_id转成数字比对，无法用索引 -
WHERE DATE(create_time) = '2024-01-01'→create_time上的索引（哪怕有）基本无效 -
WHERE mobile = '138****1234'但字段是BIGINT类型 → 字符串被转成数字，触发隐式转换
字符集和排序规则不一致也会让索引失效
当 JOIN 或 WHERE 涉及两个字段，它们的 CHARACTER SET 或 COLLATION 不同（比如一个是 utf8mb4_0900_as_cs，另一个是 utf8mb4_general_ci），MySQL 无法直接比较，会先统一转换，结果就是索引用不上。
使用场景：多库合并、历史表迁移、不同开发环境建表习惯不统一时高频出现。
- 检查方式：
SHOW CREATE TABLE tbl_name看字段定义，再对比SELECT @@character_set_database, @@collation_database - JOIN 两边字段必须字符集+排序规则完全一致，否则即使都加了索引，也可能退化为 Block Nested-Loop
- 临时修复可用
CONVERT(col USING utf8mb4) COLLATE utf8mb4_0900_as_cs，但只是掩耳盗铃，应统一源头定义
如何验证是否发生了隐式转换
最直接的办法不是猜，而是看 EXPLAIN FORMAT=TRADITIONAL 的 Extra 字段，以及启用 optimizer_trace 抓决策过程。
- 出现
Using where; Using index是理想状态；若只有Using where，说明索引只用于定位，过滤靠 server 层 - 看到
Impossible WHERE或Using temporary; Using filesort伴随索引未命中，大概率是类型/编码冲突 - 开启跟踪：
SET optimizer_trace="enabled=on";，执行 SQL 后查SELECT * FROM information_schema.OPTIMIZER_TRACE，重点看condition_processing和range_analysis节点
建表和写 SQL 时的硬性守则
预防永远比排查便宜。这两条不遵守，其他优化都是白忙。
- 索引列的类型，必须和查询中使用的字面量/参数类型严格一致：整数就传整数，字符串就传字符串，别依赖 MySQL 帮你“聪明地”转
- 所有涉及比较、JOIN、GROUP BY 的字符串字段，确保
CHARACTER SET和COLLATION全局统一，推荐utf8mb4+utf8mb4_0900_as_cs（大小写敏感、可正确处理 emoji 和部分特殊符号） - 应用层拼 SQL 时，显式类型转换比隐式更可控：比如 Java 用
String.valueOf(id)而非"" + id；Go 用fmt.Sprintf("%d", n)配合VARCHAR字段
类型转换和编码错配的问题，往往在数据量小的时候毫无征兆，等单表过千万、QPS 上千，才突然暴雷。它不报错，只悄悄变慢——这点最容易被忽略。
