sql如何优化索引？学会这几招查询快人一步！

发布日期： 2025-12-12 阅读量： 作者： admin

上个月接了个新需求，做商品搜索页优化。一上线就发现坑爹了——用户搜个关键词要等3秒才能出结果！后台监控直接飙红，吓得我赶紧查数据库。发现这破查询居然扫了全表200万条数据，我CPU风扇差点起飞。

查慢查询日志定位问题

翻出慢查询日志，抓到条祖传SQL：SELECT FROM products WHERE category_id=5 AND status=1 ORDER BY price DESC LIMIT 50。明明category_id和status都有索引，explain一看却走了全表扫描。原来这俩字段分开建的索引，数据库根本不会组合用！

动手建联合索引

当场给这俩字段建了个联合索引：ALTER TABLE products ADD INDEX idx_cat_status (category_id, status)。跑完再看执行计划，终于看见"Using index"字样了。但排序还是慢，因为price字段没加到索引里。

直接给索引加了个尾巴：DROP INDEX idx_cat_status, ADD INDEX idx_cat_status_price (category_id, status, price)。这下连ORDER BY都吃上索引了，查询速度从3秒降到0.5秒。

又掉进隐式转换的坑

还没高兴两天，运营突然说某个分类查询又变慢了。一看日志懵逼了——同样的SQL换个分类就失效。原来是开发把category_id写成字符串了！WHERE category_id='5' 这种写法导致索引失效，改回数字类型才解决。

终极优化三连招

后来在压测时又发现个问题：SELECT id,name,(SELECT count() FROM orders WHERE product_id=*) AS order_count FROM products 这种嵌套查询直接卡死。赶紧拆成两条SQL：

先查商品ID列表
再用IN()批量查订单数

顺手把SELECT 改成了具体字段，数据量直接从500kb砍到80kb。配合缓存策略，最终扛住了万人并发。

血泪史总结

这波优化搞下来，总结了几条铁律：

联合索引顺序很重要：左边字段必须是高频条件
时刻警惕类型转换：数字当字符串用就翻车
远离SELECT ：拖家带口不如精兵简政
子查询能拆就拆：分开跑比挤独木桥快十倍

现在团队规矩都改了：谁写的SQL超过100毫秒，直接请大家喝奶茶。上周靠这个办法又揪出个漏网之鱼——同事在时间范围查询里用了OR，改成UNION ALL后速度直接起飞。优化这事儿，真就是细节堆出来的胜利。

上一篇: 成品网站源码78w78隐藏通道咋找？老鸟分享实用技巧！

sql如何优化索引？学会这几招查询快人一步！

随便看看