新項(xiàng)目上線沒多久，之前數(shù)據(jù)量小瓢对，后來數(shù)據(jù)量大了寿酌，開始出現(xiàn)分頁加載慢，有時(shí)還報(bào)超時(shí)異常硕蛹，經(jīng)過排查發(fā)現(xiàn)是使用了分頁插件的數(shù)量統(tǒng)計(jì)醇疼，造成的，參考此位大佬的文章（Pagehelper分頁查詢性能優(yōu)化）法焰，然后針對(duì)mysql語句有關(guān)表連接查詢的地方秧荆，如果用不到關(guān)聯(lián)表的數(shù)據(jù)，就跟進(jìn)參數(shù)判斷是否聯(lián)表查詢埃仪，此問題得到了徹底解決乙濒，特此記錄
以下為上述鏈接的內(nèi)容：（支持原創(chuàng)，如有侵權(quán)卵蛉，請(qǐng)聯(lián)系本人颁股，本人會(huì)妥善處理）? ?
Pagehelper分頁查詢性能優(yōu)化
pageHelper單表分頁查詢的效率其實(shí)是很快的，但是對(duì)于多張表join查詢可能會(huì)導(dǎo)致分頁查詢效率變慢傻丝，主要原因出現(xiàn)在pageHelper在執(zhí)行分頁的過程中是先查詢總條數(shù)的甘有，每次分頁都是執(zhí)行這個(gè)查詢總條數(shù)的sql，這個(gè)過程是非常慢的葡缰，不過這個(gè)還是取決于數(shù)據(jù)庫中表數(shù)據(jù)量非常大的情況亏掀，像單表數(shù)據(jù)超過百萬條之后，可能會(huì)導(dǎo)致查詢sql總條數(shù)超過1分鐘泛释，那么每次分頁查詢的時(shí)間全部都浪費(fèi)在查詢總條數(shù)上了滤愕，這肯定是不可取的，pageHelper默認(rèn)是執(zhí)行當(dāng)前的查詢sql進(jìn)行查詢分頁總條數(shù)怜校，單論查詢數(shù)據(jù)是很快的
limit 10條或100條都是毫秒級(jí)別的
分頁查詢慢主要原因就出在Pagehelper默認(rèn)執(zhí)行當(dāng)前的查詢sql
不過Pagehelper優(yōu)化之后的好處就是可以手動(dòng)寫查詢總條數(shù)
在Pagehelper5.0.0以上版本支持手動(dòng)count查詢語句
示例代碼：
下面這個(gè)是查詢分頁總條數(shù)的sql（報(bào)紅是因?yàn)槲襂DEA安裝mybatis插件的原因）间影，每次查詢分頁都會(huì)執(zhí)行這條sql不過效率要比默認(rèn)的快很多，因?yàn)樗菃伪聿樵兛倵l數(shù)的茄茁，這樣的話效率提高了上百倍魂贬，當(dāng)然這是是實(shí)例代碼蔓搞，是禁止select * 的
但是這樣寫其實(shí)要考慮一個(gè)問題就是查詢的總條數(shù)是否與前臺(tái)展示的真數(shù)據(jù)是否一致，這是一個(gè)問題随橘。
所以說要保證數(shù)據(jù)條數(shù)的一致性喂分，查詢sql必須用LEFT JOIN 左連接，否則會(huì)導(dǎo)致查詢的數(shù)據(jù)量與手動(dòng)查詢總條數(shù)數(shù)據(jù)量不一致
當(dāng)然机蔗，上面的只是其中我遇到的一種情況蒲祈，分享給大家，希望能給你們帶來幫助
