MySQL索引优化实战：从3秒到300毫秒的蜕变

上周排查用户投诉时发现后台报表查询要3秒多，explain一看全表扫描直接裂开。分享下这次优化的骚操作：

1. 联合索引最左匹配原则踩坑 给status,create_time字段加了联合索引，但查询条件写成WHERE create_time>? AND status=1居然不走索引！调换字段顺序立竿见影，这波血赚。

2. 用覆盖索引避免回表 列表页只需要展示id和title，专门建了(id,title)的覆盖索引，Extra列出现Using index时真的爽到飞起。

3. 时间范围查询的索引失效 发现带TO_DAYS()函数的日期比较会导致索引失效，改成BETWEEN ? AND ?后查询计划马上变漂亮。这里埋个坑：有时间再写写datetime和timestamp的索引差异。

现在报表查询稳定在200-300ms，顺便把相似的订单查询也优化了。搞DB优化真的像玩解谜游戏，每个执行计划都是线索，改完立即看explain验证的感觉比抽卡还刺激...