做过 20+ 个系统的慢查询治理，总结出最容易踩的 10 个索引误区，每一条都真实见过翻车现场。

【误区一】索引越多越好。写库每次更新都要维护所有索引，订单表加到 15 个索引后写入延迟翻了 4 倍。

【误区二】在最左列用低区分度字段。联合索引 (status, created_at)，status 只有 4 个值，range 查询直接废掉后半段索引。正确姿势是把 created_at 放前面或做冗余。

【误区三】对索引列做函数运算。WHERE DATE(created_at) = 某天 全表扫描，改范围查询立刻走索引。

【误区四】隐式类型转换。手机号字段是 varchar 却用数字查，索引直接失效，这是线上事故常客。

【误区五】LIKE 前置百分号。一切前缀匹配之外的模糊查询都走不了 B+ 树，需求真要就上全文索引或搜索引擎。

【误区六】OR 连接非索引列。OR 两侧只要有一侧无索引就全表扫，拆成 UNION 往往更快。

【误区七】忽略覆盖索引。SELECT 指定列配合联合索引避免回表，高频列表接口提速 5-10 倍很常见。

【误区八】长字段不截断。给 varchar(255) 的 url 建全量索引，改前缀索引 + hash 列才是正解。

【误区九】信经验不信 EXPLAIN。每个可疑 SQL 都要看执行计划，rows 和 Extra 列会说真话。

【误区十】一劳永逸心态。数据分布变了索引就该重新评估，建议每季度跑一次慢查询复盘。

你踩过哪条？或者有第 11 条补充？评论区见。