正儿八经mysql优化！
mysql数据量少，优化没必要，数据量大，优化少不了，不优化一个查询10秒，优化得当，同样查询10毫秒。
这是多么痛的领悟！
mysql优化，说程序员的话就是：索引优化和where条件优化。
实验环境：MacBook Pro MJLQ2CH/A，mysql5.7，数据量：212万+
ONE：
| select * from article INNER JOIN ( SELECT id FROM article WHERE length(content_url) > 0 and (select status from source where id = article.source_id)=1 and (select status from category where id = article.category_id)=1 and status = 1 and id < 2164931 order by stick desc,pub_time desc limit 240,15 ) AS tUSING(id); |
咋一看，大佬肯定会想杀了我，没事做啥自关联，还是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：
| select * from article INNER JOIN ( SELECT id FROM article WHERE INSTR(ifnull(title,''),'战狼') > 0 and status != 9 order by pub_time desc limit 100,10 ) AS t USING(id); |
嗯——又是inner join.......
| INSTR(ifnull(title,''),'战狼') > 0，为啥不用like...... |
1.考虑到这是管理平台的搜索，没有去搜索引擎上搜，搜索引擎是一个小时才同步一次数据，数据不全。管理人员搜索时只管他要的结果，like %XX%不能走索引，效率比instr低了5倍，又测试了regexp '.*XX*.'，还是比instr耗时多一点，索性.....
| desc or explain看看，filesort.....给pub_time加个index看看，还是filesort..... |
