本文深度解析数据库索引失效的7大高频场景，提供包含联合索引使用误区、隐式类型转换等实际案例的解决方案，并给出执行计划分析方法论，帮助开发者快速定位和修复索引性能问题。
联合索引为什么总用不上？
开发者在设计复合索引时，常忽略最左前缀匹配原则。当查询条件未包含索引最左列时，MySQL优化器将放弃使用索引。例如用户表索引(user_id,create_time)结构：
CREATE INDEX idx_user_time ON users(user_id, create_time);执行SELECT FROM users WHERE create_time > ‘2023-08-01’时，索引完全失效。解决方案应采用条件重排序，将user_id加入查询条件，或单独创建create_time索引。
类型转换如何拖垮查询性能？
当字段类型与查询参数类型不一致时，会发生隐式类型转换导致索引失效。例如手机号字段定义为varchar，但查询使用数值类型：
SELECT FROM contacts WHERE phone = 13800138000;此时MySQL会执行全表扫描，正确做法是保持类型一致：phone=’13800138000’。特殊场景下可使用函数索引：
CREATE INDEX idx_phone ON contacts(CAST(phone AS UNSIGNED));模糊查询怎样正确使用索引？
LIKE语句的通配符位置决定索引有效性：
- ❌ 前导通配：WHERE name LIKE ‘%张’
- ✅ 后导通配：WHERE name LIKE ‘张%’
对于需要前后模糊匹配的场景，建议使用全文索引或Elasticsearch等专用搜索引擎。实测表明，百万级数据量下前导通配查询耗时是后导通配的47倍。
常见问题排查指南
- 如何验证索引是否生效？
- 使用EXPLAIN查看执行计划，重点观察type列（应出现ref/range）和key列（显示使用的索引）
- 索引列存在计算怎么办？
- 避免在WHERE子句中对索引列进行运算，如WHERE YEAR(create_time)=2023。应改为范围查询：WHERE create_time BETWEEN ‘2023-01-01’ AND ‘2023-12-31’
高并发场景的索引优化策略
当QPS超过2000时，需特别注意：
- 控制单表索引数量（建议不超过5个）
- 优先使用覆盖索引（Using index）
- 定期使用ANALYZE TABLE更新索引统计信息
