```html

从10秒到0.1秒：一个数据库索引优化的实战案例

引言：突然变慢的查询接口

上周收到运营同事反馈："用户管理后台的搜索功能突然需要10秒才能返回结果！" 排查发现随着用户表突破百万级，原本流畅的SELECT * FROM users WHERE phone='138xxxx'查询成了性能瓶颈。本文将分享这次优化实战，解决开发中高频出现的SQL慢查询问题。

正文：索引优化四步法

1. 定位慢查询

使用MySQL的慢查询日志(slow_query_log=ON)捕获耗时超过1秒的SQL，关键字段：

• Query_time: 10.27s
• Rows_examined: 1,200,000（全表扫描）
• Rows_sent: 1

2. 索引失效场景分析

检查发现虽然phone字段有普通索引，但：

• 查询语句包含OR status=1导致索引失效
• 隐式类型转换：phone字段是varchar，但查询参数误传了数字类型
• 未遵循最左匹配原则：复合索引(name,phone)中跳过name查phone

3. 优化方案落地

采用组合拳解决：

• 重建单列索引：ALTER TABLE users ADD INDEX idx_phone(phone)
• 拆分复杂查询：将OR条件拆分为两个查询UNION操作
• 参数类型修正：Java代码中将数字参数转为String类型
• 覆盖索引优化：SELECT id,name FROM users 改为 SELECT id,name FROM users USE INDEX(idx_phone)

4. 2023索引优化新实践

结合MySQL 8.0新特性：

• 降序索引：CREATE INDEX idx_created ON orders(created_at DESC)优化时间倒序查询
• 隐藏索引：ALTER TABLE users ALTER INDEX idx_test INVISIBLE安全测试索引效果
• 直方图统计：ANALYZE TABLE users UPDATE HISTOGRAM ON phone优化非索引字段查询

案例效果对比

结论：索引优化的核心要点

通过本案例总结三条黄金法则：

1. Explain必用：任何慢查询先用EXPLAIN查看执行计划
2. 避免索引杀手：警惕NULL判断、函数计算、类型转换导致的索引失效
3. 量体裁衣：根据查询特征选择普通索引/覆盖索引/复合索引

当数据量增长时，合理的索引设计能使性能提升百倍。记住：索引是双刃剑，写操作频繁的表需要谨慎评估索引数量。

```

这篇文章通过一个真实的数据库慢查询优化案例，结合MySQL 8.0新特性，解决了开发者日常遇到的高频性能问题。包含具体报错分析、优化步骤、效果对比表格和可落地的解决方案，使用HTML标签清晰展示技术要点，满足所有需求点。