mysql大数据查询优化的示例分析

这篇文章给大家分享的是有关mysql大数据查询优化的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。mysql数据量少,优化没必要,数据量大,优化少不了,不优化一个查询10秒,优化得当,同样查询10毫秒。这是多么痛的领悟!mysql优化,说程序员的话就是:索引优化和where条件优化。实验环境:MacBook Pro MJLQ2CH/A,mysql5.7,数据量:212万+ONE:
咋一看,大佬肯定会想杀了我,没事做啥自关联,还是inner join。XX楼的,把我的杀猪刀拿来,我要宰了博主!!!说实话,早上出门我的脑袋没被门挤,我也不想这样的。1.数据量大了,你要做offset很大的分页查询,还真的这样提速,原因 —> 用join子表中的id覆盖到全表,避免全表扫描。看我的order by(细语:不就是个order by,TM谁不会写),你把这个order by换成你自己的表中的字段desc or explain看看。Extra —> filesort ! shit !2.针对这种多个条件的order by,通常我们会直接给两个字段分别加index,然而还是会Extra —> filesort。另辟蹊径,给order by后面的所有条件加一个联合索引,注意顺序一定要和你的order by顺序一致。这样Extra就只剩下where了。再看看where,(select status from source where id = article.source_id)=1 and ...又啥JB写法!3.想过用join+index的方式,最后测试出来,和这种方式几乎无差别。生产环境是这样写的,那就这样吧,还能少两个索引(source_id,category_id),懒病犯了谁都阻挡不了,以后吃亏了又回来继续优化呗。4.这个点是我昨晚才get到的,where条件的满足顺序是优先满足最后一个条件,从右到左,经过删除index测试,确实有效果,能从6秒降到4秒,优化了index之后再次测试发现顺序对耗时影响几乎可以忽略不计,0.X毫秒。TWO:嗯——又是inner join…….1.考虑到这是管理平台的搜索,没有去搜索引擎上搜,搜索引擎是一个小时才同步一次数据,数据不全。管理人员搜索时只管他要的结果,like %XX%不能走索引,效率比instr低了5倍,又测试了regexp ‘.*XX*.’,还是比instr耗时多一点,索性…..2.这种情况有另外一种方案,SELECT id FROM article force index(pub_time),指定使用这个索引。但是这种写法太缺灵活性了,OUT!百度一下,有高人指点迷津:把status和pub_time建个联合索引(pub_time_status,order的条件在前),让where查询的时候,把这个index自动force上。THREE:好吧,我也不知道,把status和pub_time再建个联合索引status_pub_time,这次where条件在前,expla开发云主机域名in没filesort了,但是这个index却没有被使用,它勾搭出了pub_time_status。搞不懂啊同时我又explain了TWO的SQL,都是如下图:这二者中删除任何一个都不行,删除一个,就有sql会filesort!FOUR:看看这三句sql,interesting,是不是!为了公平起见,我已经优化了索引,user_id_sort(user_id,sort),让where在用user_id判断时force上这个索引。第一句:0.48ms第二句:0.42ms第三句:6ms,导致时间长那么多的原因是union(查询两次表,合并成子表)后不能用index覆盖到order by的sort上有的时候union不一定比or快。感谢各位的阅读!关于“mysql大数据查询优化的示例分析”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!

相关推荐: 如何配置mysql

这篇文章将为大家详细讲解有关如何配置mysql,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。如何配置mysql1.进入mysql配置向导2.选择配置方式3.选择服务器类型,根据自己需求4.选择mysql数据库的…

免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 06/20 10:31
下一篇 06/20 10:31

相关推荐

发表评论

您的电子邮箱地址不会被公开。