mysql索引优化案例

文章探讨了在MySQL查询中,如何正确选择索引以提高性能,特别是在案例1中,当查询条件可能导致大量磁盘IO时,应强制使用更合适的索引。案例2中提到使用`orderby`可能导致额外的磁盘I/O,解决方法包括使用函数操作绕过索引或考虑数据结构的调整。建议在业务中谨慎使用orderby,以防止选错索引。
摘要由CSDN通过智能技术生成

案例1

select * from      order where   user_id =11 and status = 1 and id > 10000 limit 10

2个索引 user_id 、  id

场景

  偶然会查询的慢,且不容易复现 

原因

id大的时候,mysql评估后使用id更快;但是实际上会多几次IO查询

(总共1000W条数据,>999.9W,limit 从倒数1000条查询。。假如这1000条只有最后1条是复核条件的,那么:就会从磁盘扫描出这1000条数据,然后比较user_id。 假如10条数据是1个page, 1000条数据要100个page,也就是100次磁盘IO,因此使用id索引会慢)

解决方案

强制使用 user_id 索引

案例2

查询未归档的订单(未归档的数据量,因此status创建了索引能有效筛选出数据)

select * from order where  status =10  order by   update_time

索引

2个索引 status  , update_time

问题

使用 update_time 索引,能避免排序;但是,会增加磁盘IO

解决方案

select * from order where  status =10  order by  update_time+0

update_time +0 后,就无法利用 update_time 索引(因为 对字段做了函数操作)

其他方案

  1. 强制索引
  2. 可使用“将待归档的数据” 放入到另一张表
  3.  将待归档的数据 使用redis中sortSet存储

建议:

业务中慎用 order by ,会引起 选错索引

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值