MyBatis-Plus 长SQL查询性能问题分析与优化实践

问题现象

在使用MyBatis-Plus 3.5.3.2版本的项目中，开发人员遇到了一个特殊的性能问题：当执行包含复杂子查询和UNION操作的长SQL语句时，项目刚启动时查询速度正常(20-200ms)，但随着运行时间增长(约一天后)，查询性能急剧下降至20-30秒，同时伴随CPU使用率飙升。重启应用后问题暂时消失。

问题SQL分析

问题SQL是一个复杂的统计查询，主要特点包括：

1. 包含多个子查询和UNION ALL操作
2. 涉及三张表的关联统计(mt_order, mt_order_refund, third_party_verify_record)
3. 使用日期分组统计和复杂的条件判断
4. 包含动态条件(poiIds集合参数)

SQL结构大致分为三个主要部分，每部分都包含子查询并通过UNION ALL组合结果，最后进行排序输出。

可能原因分析

1. SQL解析缓存问题

MyBatis会对SQL进行解析和缓存，复杂的SQL可能会占用较多缓存资源。随着时间推移，缓存管理可能出现问题，导致每次执行都需要重新解析SQL。

2. 连接池配置不当

项目使用HikariCP连接池，配置了最大50个连接。可能出现：

• 连接泄漏导致可用连接减少
• 连接回收不及时
• 连接验证开销过大

3. 结果集处理开销

该查询返回几百行数据，MyBatis需要将这些结果映射为Java对象。随着运行时间增长，可能因内存管理问题导致对象创建开销增大。

4. 参数处理问题

SQL中使用${}直接拼接参数而非预编译的#{}，虽然这不是性能问题的直接原因，但可能影响SQL执行计划缓存。

5. JVM内存问题

长时间运行后可能出现内存碎片或特定区域(如老年代)占用过高，影响对象创建和垃圾回收效率。

解决方案建议

1. 升级相关组件

• 将MyBatis-Plus升级到最新稳定版
• 更新数据库驱动到最新版本
• 考虑使用性能更好的连接池(如Druid)

2. 优化SQL实现

• 考虑将复杂SQL拆分为多个简单查询，在Java层组装结果
• 使用存储过程替代复杂查询
• 添加适当的索引优化查询性能

3. 调整连接池配置

# 增加泄漏检测阈值
spring.datasource.hikari.leak-detection-threshold=60000

# 调整连接生命周期
spring.datasource.hikari.max-lifetime=600000
spring.datasource.hikari.idle-timeout=300000

4. 监控措施

• 实施SQL执行监控，记录执行时间和参数
• 添加JVM内存监控，观察GC行为
• 使用连接池监控功能检查连接状态

5. 代码层面优化

• 对大数据量结果集考虑使用流式查询
• 检查实体类映射配置，确保没有不必要的复杂类型处理
• 考虑使用MyBatis的二级缓存(需谨慎评估适用性)

预防措施

1. 对复杂查询实施性能基准测试
2. 建立长期运行测试环境模拟生产情况
3. 实施全面的应用性能监控(APM)
4. 定期进行JVM性能调优
5. 建立查询评审机制，控制SQL复杂度

总结

MyBatis-Plus项目中长SQL查询的性能问题通常是多方面因素共同作用的结果。通过系统性的分析和有针对性的优化，可以有效解决这类性能衰减问题。关键在于建立完整的监控体系，确保能够快速定位性能瓶颈，并采取适当的优化措施。