背景

我們有個業務服務長期沒有進行過上線，但是服務器監控經常會發生報警，提示 cpu 使用率 100% 影響線上生產。偶發的現象，所以一開始沒注意，后續經過排查才發現原來是踩中了一個“坑”。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

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

排查過程

1、首先排除了新業務上線的問題

2、其次通過服務器的監控排除了硬件故障的問題

3、于是使用 java 線程分析工具，分析了導致 cpu 過高的都是哪些線程

發現異常線程

排查就會發現 mybatis 執行的相關線程。

4、于是我們根據提示找到相應的源碼處進行分析。mybatis 組裝 sql 語句這里，這段代碼，在 sql 很長的并且入參很多說的時候，下面對 sql 的拼接，將#{屬性名}替換成?是很耗費 cpu 的。

MyBatis拼接大SQL耗費性能

5、那么導致這個問題的原因是什么呢？我們針對 mapper 里的 sql 語句發現，有個查詢條件入參是個 list，mapper 是這么寫：

foreach

6、為了驗證問題，我們自己做了一個測試，通過入參條件的調整，來進行執行時間的監控驗證，最后經過反復的測試發現「當入參 list 的數量達到 10 萬級別的時候，cpu 就飆升到了 120%，執行了 29s，是造成線程等待的元兇」

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://gitee.com/zhijiantianya/yudao-cloud

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

總結

「在使用 list 做 mapper 入參，一定要考慮上限」

另外，sql 的 in 里面的數據也太多了吧，sql 太長超過 max_allow_packet 會報錯的。這個 MySQL 配置，建議不要往大了改！

審核編輯：劉清