這篇文章給大家分享的是有關(guān)MySQL大數(shù)據(jù)查詢優(yōu)化的示例分析的內(nèi)容。小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過來看看吧。

十余年的朝天網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。網(wǎng)絡(luò)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整朝天建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“朝天網(wǎng)站設(shè)計(jì)”,“朝天網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

mysql數(shù)據(jù)量少，優(yōu)化沒必要，數(shù)據(jù)量大，優(yōu)化少不了，不優(yōu)化一個(gè)查詢10秒，優(yōu)化得當(dāng)，同樣查詢10毫秒。

這是多么痛的領(lǐng)悟！

mysql優(yōu)化，說程序員的話就是：索引優(yōu)化和where條件優(yōu)化。

實(shí)驗(yàn)環(huán)境：MacBook Pro MJLQ2CH/A，mysql5.7，數(shù)據(jù)量：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 t
USING(id);

咋一看，大佬肯定會(huì)想殺了我，沒事做啥自關(guān)聯(lián)，還是inner join。XX樓的，把我的殺豬刀拿來，我要宰了博主！！！

說實(shí)話，早上出門我的腦袋沒被門擠，我也不想這樣的。

1.數(shù)據(jù)量大了，你要做offset很大的分頁查詢，還真的這樣提速，原因 ---> 用join子表中的id覆蓋到全表，避免全表掃描。

看我的order by（細(xì)語：不就是個(gè)order by，TM誰不會(huì)寫），你把這個(gè)order by換成你自己的表中的字段desc or explain看看。Extra ---> filesort ! shit !

2.針對(duì)這種多個(gè)條件的order by，通常我們會(huì)直接給兩個(gè)字段分別加index，然而還是會(huì)Extra ---> filesort。另辟蹊徑，給order by后面的所有條件加一個(gè)聯(lián)合索引，注意順序一定要和你的order by順序一致。這樣Extra就只剩下where了。

再看看where，(select status from source where id = article.source_id)=1 and ...又啥JB寫法！

3.想過用join+index的方式，最后測(cè)試出來，和這種方式幾乎無差別。生產(chǎn)環(huán)境是這樣寫的，那就這樣吧，還能少兩個(gè)索引（source_id，category_id），懶病犯了誰都阻擋不了，以后吃虧了又回來繼續(xù)優(yōu)化唄。

4.這個(gè)點(diǎn)是我昨晚才get到的，where條件的滿足順序是優(yōu)先滿足最后一個(gè)條件，從右到左，經(jīng)過刪除index測(cè)試，確實(shí)有效果，能從6秒降到4秒，優(yōu)化了index之后再次測(cè)試發(fā)現(xiàn)順序?qū)臅r(shí)影響幾乎可以忽略不計(jì)，0.X毫秒。

TWO：

 select * from article
 INNER JOIN (
 SELECT id FROM article WHERE INSTR(ifnull(title,''),'戰(zhàn)狼') > 0 and status != 9
 order by pub_time desc
 limit 100,10

 ) AS t USING(id);

嗯——又是inner join.......

INSTR(ifnull(title,''),'戰(zhàn)狼') > 0，為啥不用like......

1.考慮到這是管理平臺(tái)的搜索，沒有去搜索引擎上搜，搜索引擎是一個(gè)小時(shí)才同步一次數(shù)據(jù)，數(shù)據(jù)不全。管理人員搜索時(shí)只管他要的結(jié)果，like %XX%不能走索引，效率比instr低了5倍，又測(cè)試了regexp '.*XX*.'，還是比instr耗時(shí)多一點(diǎn)，索性.....

desc or explain看看，filesort.....給pub_time加個(gè)index看看，還是filesort.....

2.這種情況有另外一種方案，SELECT id FROM article force index(pub_time)，指定使用這個(gè)索引。但是這種寫法太缺靈活性了，OUT！百度一下，有高人指點(diǎn)迷津：把status和pub_time建個(gè)聯(lián)合索引（pub_time_status，order的條件在前），讓where查詢的時(shí)候，把這個(gè)index自動(dòng)force上。

THREE：

select * from article where status != 9 order by pub_time desc limit 100000,25;
desc or explain，還是filesort.....前面不是給status和pub_time建了聯(lián)合索引了嗎，tell me why......

好吧，我也不知道，把status和pub_time再建個(gè)聯(lián)合索引status_pub_time，這次where條件在前，explain沒filesort了，但是這個(gè)index卻沒有被使用，它勾搭出了pub_time_status。搞不懂啊

同時(shí)我又explain了TWO的SQL，都是如下圖：

這二者中刪除任何一個(gè)都不行，刪除一個(gè)，就有sql會(huì)filesort！

FOUR：

SELECT * from follow
 where (((SELECT status FROM source WHERE id=follow.source_id)=1 and follow.type=1) or ((select status from topic WHERE id=follow.source_id)=1 and follow.type=2)) AND user_id=10054
 ORDER BY sort limit 15,15;
 SELECT * from follow inner join(
 SELECT id from follow
 where (((SELECT status FROM source WHERE id=follow.source_id)=1 and follow.type=1) or ((select status from topic WHERE id=follow.source_id)=1 and follow.type=2)) AND user_id=10054
 ORDER BY sort limit 15,15
 ) as t using(id);
 (SELECT id, source_id, user_id, temporary, sort, follow_time, read_time,type from follow where (SELECT status FROM source WHERE id=follow.source_id)=1 and follow.type=1 and user_id=10054)
 union all
 (SELECT id, source_id, user_id, temporary, sort, follow_time, read_time,type from follow where (select status from topic WHERE id=follow.source_id)=1 and follow.type=2 and user_id=10054)
 ORDER BY sort limit 15,15;

看看這三句sql，interesting，是不是！

為了公平起見，我已經(jīng)優(yōu)化了索引，user_id_sort(user_id,sort)，讓where在用user_id判斷時(shí)force上這個(gè)索引。

第一句：0.48ms

第二句：0.42ms

第三句：6ms，導(dǎo)致時(shí)間長(zhǎng)那么多的原因是union(查詢兩次表，合并成子表)后不能用index覆蓋到order by的sort上

有的時(shí)候union不一定比or快。

感謝各位的閱讀！關(guān)于“mysql大數(shù)據(jù)查詢優(yōu)化的示例分析”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！

網(wǎng)頁標(biāo)題：mysql大數(shù)據(jù)查詢優(yōu)化的示例分析
轉(zhuǎn)載來源：http://www.chinadenli.net/article38/pidspp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、微信公眾號(hào)、響應(yīng)式網(wǎng)站、服務(wù)器托管、商城網(wǎng)站、標(biāo)簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)