上一篇给小伙伴们讲了关于SQL查询性能优化的相关技巧,一个好的查询SQL离不开合理的索引设计.这篇小二就来唠一唠怎么合理的设计一个索引来优化我们的查询速度,要是有不合理的地方...嗯..
当然啦,开个玩笑,欢迎小伙伴们指正！
通常情况下,字段类型的选择是需要根据业务来判断的,通常需要遵循以下几点.
下列各种类型表格内容来自菜鸟教程,权当备忘.
优化建议：
通常来说,考虑好表中每个字段应该使用什么类型和长度,建完表需要做的事情不是马上建立索引,而是先把相关主体业务开发完毕,然后把涉及该表的SQL都拿出来分析之后再建立索引.
尽量少建立单值索引( 唯一索引除外 ),应当设计一个或者两三个联合索引,让每一个联合索引都尽量去包含SQL语句中的 where、order by、group by 的字段,同时确保联合索引的字段顺序尽量满足SQL查询的最左前缀原则.
如果对这种小基数字段建立索引的话,因为索引树中只有男、女、保密三个值,根本没法进行快速的二分查找,同时还需要回表查询,还不如全表扫描嘞.
一般建立索引,尽量使用那些基数比较大的字段,那么才能发挥出B+树快速二分查找的优势来.
在 where 和 order by 出现索引设计冲突时,是优先针对where去设计索引?还是优先针对order by设计索引?
通常情况下都是优先针对 where 来设计索引,因为通常情况下都是先 where 条件使用索引快速筛选出来符合条件的数据,然后对进行筛选出来的数据进行排序和分组,而 where 条件快速筛选出来的的数据往往不会很多.
对生产实际运行过程中,或者测试环境大数据量测试过程中发现的慢查询SQL进行特定的索引优化、代码优化等策略.
终于轮到实战了,小二最喜欢实战了.
写到这里不得不吐槽一下,这个金三银四的跳槽季节,年前提离职了,结果离职还没办完就封村整整两个礼拜了,呜呜呜...
上节小二就提到会有个很有意思的小案例,那么在疫情当下,门都出不去的日子,感觉这个例子更有意思了,咱们来讨论一下各种社交平台怎么做的用户信息搜索呢.
社交平台有一个小伙伴们都喜欢的功能,搜索好友信息,比如小二熟练的点开省份...城市..性别..年龄..身高...
咳咳咳...小二怎么可能干这种事情,小二的心里只有代码,嗯...没错,就是这样.
这个就可以说是对于用户信息的查询筛选了,通常这种表都是非常大数据量的,在不考虑分库分表的情况下,怎么通过索引配合SQL来优化呢?
通常我们在编写SQL是会写出类似如下的SQL来执行,有 where、order by、limit 等条件来查询.
那么此时此刻呢小二一个一个慢慢增加字段来分析分析,怎么根据业务场景来设计索引.
针对这种情况,很简单,设计一个联合索引 (provice, city, sex) 就完事了.
那么这时候有小伙伴就会说了,很简单啊,范围字段放最后咱还是知道的,联合索引改成 (provice, city, sex, age) 不就可以了.
嗯,是的,这么干没毛病,但是小伙伴们有没有想过有些人万一既喜欢帅哥又喜欢美女,别想歪了哈...,挺多小姐姐就既喜欢帅哥又喜欢美女的.
那么这个时候小姐姐就不搜索性别了,那么这个时候联合索引只能用到前两个字段了,那么不符合咱们的专业标准啊,咋办呢?这时候还是有办法的,咱们只需要动动小脑袋改改SQL就行了,在没有选择性别时判断一下,改成下面这样就可以了.
咋办嘞,同样往联合索引里面塞,例如 (provice, city, sex, hobby, xx, age) .
针对这种多个范围查询的话,为了比较好的利用索引,在业务允许的情况下可以使用固定范围,然后数据库字段存储范围标识就可以了,这样就转化为了等值匹配,就可以很好地利用索引了.
那么根据场景最后设计出来的这个索引可能已经可以覆盖大部分的查询流量了,那么如果还有其他一部分热度比较高的查询怎么办呢,办法也很简单啊,再加一两个索引即可.
例如通常会查询这个城市比较受欢迎(评分：score)的小姐姐,这时候添加一个联合索引 (provice, city, sex, score) 那么就可以了.
以上就是土嘎嘎小编为大家整理的mysql从索引怎么优化相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！