背景

我們有個(gè)業(yè)務(wù)服務(wù)長(zhǎng)期沒(méi)有進(jìn)行過(guò)上線(xiàn)，但是服務(wù)器監(jiān)控經(jīng)常會(huì)發(fā)生報(bào)警，提示 cpu 使用率 100% 影響線(xiàn)上生產(chǎn)。偶發(fā)的現(xiàn)象，所以一開(kāi)始沒(méi)注意，后續(xù)經(jīng)過(guò)排查才發(fā)現(xiàn)原來(lái)是踩中了一個(gè)“坑”。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

排查過(guò)程

1、首先排除了新業(yè)務(wù)上線(xiàn)的問(wèn)題

2、其次通過(guò)服務(wù)器的監(jiān)控排除了硬件故障的問(wèn)題

3、于是使用 java 線(xiàn)程分析工具，分析了導(dǎo)致 cpu 過(guò)高的都是哪些線(xiàn)程

發(fā)現(xiàn)異常線(xiàn)程

排查就會(huì)發(fā)現(xiàn) mybatis 執(zhí)行的相關(guān)線(xiàn)程。

4、于是我們根據(jù)提示找到相應(yīng)的源碼處進(jìn)行分析。mybatis 組裝 sql 語(yǔ)句這里，這段代碼，在 sql 很長(zhǎng)的并且入?yún)⒑芏嗾f(shuō)的時(shí)候，下面對(duì) sql 的拼接，將#{屬性名}替換成?是很耗費(fèi) cpu 的。

MyBatis拼接大SQL耗費(fèi)性能

5、那么導(dǎo)致這個(gè)問(wèn)題的原因是什么呢？我們針對(duì) mapper 里的 sql 語(yǔ)句發(fā)現(xiàn)，有個(gè)查詢(xún)條件入?yún)⑹莻€(gè) list，mapper 是這么寫(xiě)：

foreach

6、為了驗(yàn)證問(wèn)題，我們自己做了一個(gè)測(cè)試，通過(guò)入?yún)l件的調(diào)整，來(lái)進(jìn)行執(zhí)行時(shí)間的監(jiān)控驗(yàn)證，最后經(jīng)過(guò)反復(fù)的測(cè)試發(fā)現(xiàn)「當(dāng)入?yún)?list 的數(shù)量達(dá)到 10 萬(wàn)級(jí)別的時(shí)候，cpu 就飆升到了 120%，執(zhí)行了 29s，是造成線(xiàn)程等待的元兇」

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶(hù)小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶(hù)、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://gitee.com/zhijiantianya/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

總結(jié)

「在使用 list 做 mapper 入?yún)ⅲ欢ㄒ紤]上限」

另外，sql 的 in 里面的數(shù)據(jù)也太多了吧，sql 太長(zhǎng)超過(guò) max_allow_packet 會(huì)報(bào)錯(cuò)的。這個(gè) MySQL 配置，建議不要往大了改！

審核編輯：劉清