莫一哲

VUE版本正在开发中,这个golang template版本即将退役 2018-11-07 22:29 by fifsky

玥玥开始攒肚了,每日每夜的睡,这爹妈不好当啊,不睡吧崩溃,睡不醒吧又担心是不是有问题~~ 2018-10-26 09:00 by fifsky

小玥儿满月了,能吃能睡,一切安好 2018-10-21 20:19 by fifsky

驱车来回500公里给小家伙上户口,我们家第一个城市身份证号码诞生了 2018-09-30 18:46 by fifsky

折磨我的老腰啊,可是这个小家伙依然没有出来的意思 2018-09-13 19:40 by fifsky

是时候学习VUE了,为了防止被前端淘汰 2018-08-24 01:04 by fifsky

Ant Design 无法保证业务产品能否成功,但是能帮助业务产品『正确的成功』或者『正确的失败』 2018-08-22 14:19 by fifsky

我慢慢地品,雪落下的声音,仿佛是你贴着我叫卿卿 2018-08-19 10:41 by fifsky

想写一点骚柔的文字,可以盯着屏幕久久的不知道该写点什么 2018-07-28 23:58 by fifsky

现在很少听李志的歌了,有人说,是现在的生活没那么苦了,可是,也许我们早已经习惯生活的苦了,致敬,逼哥的歌 2018-03-08 13:49 by fifsky

mysql大数据量order by导致速度变慢

最近处理一个3700W的数据,其中一个字段使用的全文检索,索引比较大达到5G,测试的时候还挺快的,放到服务器之后变慢了,一开始以为是索引出问题(因为服务器的索引文件MDI是直接从本地拷贝到服务器的),后来发现本地也变慢了,对sql分析之后发现问题,一开始我测试的时候SQL是不加order by的如


SELECT * FROM yuliao WHERE MATCH(split_content) 
AGAINST ('我们' IN BOOLEAN MODE) limit 100


速度很快基本是毫秒级别,后来画蛇添足加了order by之后


SELECT * FROM yuliao WHERE MATCH(split_content) 
AGAINST ('我们' IN BOOLEAN MODE) order by id asc limit 100


这下居然需要21秒了,explain一下发现Using where; Using filesort,走的是fulltext的全文检索,并对内容重新排序,错就错在为毛要对结果集重新排序呢?,为毛不走id主键索引?这个需求为毛尚且可以去除order by id asc,因为默认就是走主键索引的,但是如果需求是需要order by id desc呢,测试表明同样很慢,目前只想到强制走id索引的方法解决,如下


SELECT * FROM yuliao force index(primary) WHERE MATCH(split_content) 
AGAINST ('我们' IN BOOLEAN MODE) order by id desc limit 100


如果你有更好的方案,欢迎留言讨论


  • 1
返回顶部