索引失效的典型原因是类型不匹配：字符串字段用数字查询（如phone=138...）、INT字段用字符串条件（如id='123'）、JOIN字段类型不一致，均触发隐式转换，使B+树无法跳查，导致全表扫描。
字符串字段用数字查询、INT字段用字符串条件、JOIN字段类型不一致——这三类情况只要出现，索引大概率直接作废，EXPLAIN里一眼就能看到 type=ALL。
WHERE 条件中字段类型与值类型不一致
最常见也最容易忽略：明明 phone 是 varchar，却写成 WHERE phone = 13812345678。MySQL 会悄悄把整列的 phone 值转成数字再比对，等价于在索引列上加了隐式函数，B+树无法跳查，只能全扫。
- ✅ 正确写法：
WHERE phone = '13812345678'（字符串字段，值必须加单引号） - ❌ 错误写法：
WHERE phone = 13812345678（触发隐式转换，索引失效） - ⚠️ 特别注意：PHP/Java 等语言拼 SQL 时，若变量未显式转字符串，极易漏掉引号；JSON 解析后数字类型未 toString()，也会踩坑
JOIN 时关联字段类型不同
两张表用 code 关联，但 table_a.code 是 varchar(20)，table_b.code 是 bigint，哪怕两边都有索引，JOIN 条件一执行，MySQL 就得把其中一列全部转类型，索引立刻失效。
- ✅ 首选方案：统一字段类型，例如都改成
varchar(20)或都改成bigint（需评估数据兼容性） - ✅ 次选方案（数据量大/不能改表时）：在查询中显式转换，例如
ON a.code = CAST(b.code AS CHAR)或ON CAST(a.code AS SIGNED) = b.code，让转换逻辑可控且可预测 - ? 检查方法：
SHOW CREATE TABLE table_a;和SHOW CREATE TABLE table_b;对比字符集、排序规则、数据类型
如何确认是否发生了隐式转换
光看 SQL 不够，必须靠 EXPLAIN 和警告信息交叉验证。
- 看查看
EXPLAIN输出中的type字段：如果是ALL或index（而非ref/range），先怀疑类型问题 - 执行完
EXPLAIN后，立即执行SHOW WARNINGS;—— 如果有隐式转换，这里通常会显示类似Warning 1739 | Cannot use ref access on index 'xxx' due to type or collation conversion - 用
SELECT @@sql_mode;确认是否启用了STRICT_TRANS_TABLES，它会让部分隐式转换报错而非静默降级
强制类型转换不是万能解药
用 CAST() 或 CONVERT() 能绕过自动转换，但代价是：它本质上仍是“在索引列上做运算”，只是你写的明面上的函数。如果转换导致无法利用索引有序性（比如把 varchar 强转成 date 再比较），依然无效。
- ✅ 安全用法：
WHERE CAST(create_time AS DATE) = '2024-01-01'→ 改为WHERE create_time >= '2024-01-01' AND create_time （保留原始列参与比较） - ❌ 危险用法：
WHERE CAST(phone AS UNSIGNED) = 13812345678→ 仍会全表扫描，且可能因非法字符报错 - ? 核心原则：让索引列以原始类型出现在
=、IN、BETWEEN等可走索引的操作符左侧，不做任何包装
