为什么mysql数据库查询加了索引的字段仍然很慢?
最近在开发一个推广渠道自行查询订单的功能,因为几年下来,平台的订单量也有百万级别了,发现虽然在用渠道ID字段查询时,虽然渠道ID加了索引,但仍然需要13秒左右才能拿到查询结果,我的订单表结构如下(下面只列出了跟本主题相关的列):
| id(主键) | channelId(渠道id,索引列) | createTime(创建时间,索引列) |
|---|
,我的SQL是这样的:
SELECT id,channelid,createTime FROM
orderWHERE channelId=’1’ ORDER BY createTime DESC LIMIT 20
我的感觉以现有数据库服务器的配置,这个数据量应该不至于这么慢的,于是用Explain命令分析了一下,结果如下图:
| id | table | Type | Possibole_keys | key | Extra |
|---|---|---|---|---|---|
| 1 | Order | Index | channelId | createTime | Using where |
Mysql是用了createTime作为查询的索引,跟预想的情况不大一样,分析了一下原因,可能是Mysql默认认为排序列索引的优先级比条件里的高吧,又或者因为createTime字段值本身更分散一些,所以Mysql优先使用了这列作为查询索引。
从这个场景可以看出实际上任何一下数据库的查询分析器都不是万能的,虽然本身它们在算法上都有做了优化,会尝试去找到最佳的筛选方式,但不是所有的情况下都管用,程序员必须带着辩证的思维方式去看待,遇到问题时要认真分析而不是盲目地相信数据库一定会做出最好的选择。因为索引的目的是为了快速缩小查找范围,但在这条SQL里,创建时间仅用来排序,是它来做索引是无法快速缩小范围的,而用渠道id来做索引则能迅速地缩小范围,所以尝试使用了USE INDEX(channelId)方法指定使用索引,果然查询速度有了20倍的提升(由原来的13.45秒提升到0.58秒),SQL性能优化确实是无止境的,永远都有提升空间。
附上加了USE INDEX指令的SQL:
SELECT id,channelid,createTime FROM
orderUSE INDEX(channelId) WHERE channelId=’1’ ORDER BY createTime DESC LIMIT 20
本文通过实际案例,探讨了MySQL数据库中索引的正确使用方法。作者在开发推广渠道订单查询功能时,发现即使已为渠道ID字段添加索引,查询速度仍然缓慢。通过深入分析并使用USE INDEX指令,成功将查询时间从13.45秒优化至0.58秒,揭示了索引优化的重要性和技巧。
1716

被折叠的 条评论
为什么被折叠?



