写在前面
在前一篇文章中,我们已经介绍了索引、索引的优化规则等等 原文链接:Siam博客 mysql索引优化 在其中我们有引申出组合索引
,多个单字段索引冲突
两个知识点。 本文章主要是与后者有关联。 在原文中,我们使用了下面的例子
现在有这样子的数据量:
100W条数据 user_name=’我是用户名’
100条数据 user_phone=’110′
5条数据 user_name=’我是用户名’ and user_phone=’110′
假设有这样子一条语句:
select * from test where user_name = '我是用户名' and user_phone='110'
有两个字段都有索引可用,mysql会选择一个使用。这是属于mysql的内部处理判断
正常情况下,如果用user_phone索引生效的话,会很快得到结果(先筛选出100条 再筛选)
如果user_name生效,则要先筛选100W条数据,再筛选user_phone
mysql内部的错误判断可能使得user_name索引生效,此时效率就会很低了,我们可以强制使用某个索引
指定使用索引的意义
从以上例子中,我们可以思考并归纳。能提升效率的核心是:在一开始就尽可能地筛选出准确的数据
。 所以当我们发现mysql可能处理出错的情况时,可以手动指定使用更优的索引来提高查询效率。 这个可以称为索引降维
。
降维
数据的选择度越大,则维度越大。 降维,按我个人的理解是:在大量的数据中,一层一层地筛选过滤,维度也会逐渐减低。 点线面中,共有黑红两种颜色。 目标:筛选出所有红色的点 步骤:选出所有带有红色点的面 --> 选出所有带有红色点的线 --> 在线上选出所有红色点
索引降维
在老旧的mysql版本中,where的条件顺序还会很大影响执行结果。 比如在上面的举例中,用条件语句来举例,而不是索引
select * from test where user_name = '我是用户名' and user_phone='110'
select * from test where user_phone='110' and user_name = '我是用户名'
这两个语句会出现上面索引冲突时 mysql没有使用更优索引的情况一样,第一条语句会先筛选出100W条数据,再筛选user_phone=110
然而在后续的mysql发展中,sql构造器优化器会自动帮我们排序执行,这种问题已不太需要人工去调整。
但是当我们建立组合索引的时候,则会根据我们的选择顺序来构建了。 比如有这么一个索引
index user_info (user_name, user_phone)
我们可以用大小分类的情况举例看一下
└名字一
└──user_phone 110
└──user_phone 120
└──user_phone 119
└名字二
└──user_phone 110
└──user_phone 120
└──user_phone 119
└名字三
└──user_phone 110
└──user_phone 120
└──user_phone 119
而如果我们把顺序调整成(user_phone, user_name)
那么就可以把组合索引看成
└─110
└──user_name 名字一
└──user_name 名字二
└──user_name 名字三
└─120
└──user_name 名字一
└──user_name 名字二
└──user_name 名字三
└─119
└──user_name 名字一
└──user_name 名字二
└──user_name 名字三
两种情况,都会在某些场景下有自己的优势,所以我们就需要结合自己的业务数据
来进行选择啦。 用我们的老例子来说: 以名字来区分,第一次筛选出现100W条数据,然后再筛选手机号。 以手机号来区分,第一次筛选出现100条数据,然后再筛选用户名。 同样的情况还出现在分表
中,用什么条件来分表也是极其重要的。 分表中,如果我们以订单的年份作为分表条件,想要搜索ID=3的会员在2019年某个月份日期的订单,那么我们需要先搜索2019年的表(一年的订单假设有100W条记录),然后再筛选用户ID和其他月份等条件。 如果我们以订单的年份+月份作为分表条件(只是举例,有很多分表条件可以决定),那么初步筛选的数据就会少了很多了,后续的筛选步骤也会更快完成。
总结
在分表、组合索引等等场景下,我们可以结合业务数据,进行降维的顺序思考,尽可能地在一开始就筛选出比较准确的数据
,在后续的筛选中则只需要遍历检查很少的一部分数据,已达到提高查询效率的效果。
扫描二维码,分享此文章