MyBatis-Plus多租户插件异步缓存导致的SQL拼接问题分析

问题背景

在使用MyBatis-Plus 3.5.10.1版本时，开发者发现当开启多租户插件并配合异步缓存功能时，生成的SQL语句中会出现重复拼接租户ID条件的情况。例如，原本应该只出现一次的tenant_id = 0条件，在实际生成的SQL中却出现了两次。

问题现象

具体表现为执行查询时，生成的SQL语句如下：

SELECT id, name, tenant_id 
FROM t_user 
WHERE (name = ? AND id = ?) 
AND tenant_id = 0 
AND tenant_id = 0

这种重复的条件拼接不仅影响SQL执行效率，还可能导致潜在的逻辑问题。

技术原理分析

MyBatis-Plus的多租户功能是通过TenantLineInnerInterceptor拦截器实现的。该拦截器会在SQL解析阶段自动为SQL语句添加租户条件。而JSQLParser的缓存机制则用于提高SQL解析的性能。

当开启异步缓存功能时，系统会使用FurySerialCaffeineJsqlParseCache作为缓存实现，该缓存支持异步写入操作。问题就出在这种异步处理机制上。

根本原因

在异步缓存模式下，SQL解析和租户条件添加的过程可能出现竞态条件：

1. 第一次解析SQL时，租户条件被正确添加
2. 由于异步写入缓存，缓存可能尚未完全更新
3. 第二次解析相同SQL时，系统可能再次添加租户条件
4. 最终导致SQL中出现重复的租户条件

解决方案

MyBatis-Plus官方已经确认这是一个bug，并提供了以下解决方案：

1. 临时解决方案：关闭异步缓存功能，使用同步模式
2. 长期解决方案：升级到3.5.11或更高版本，这些版本中可能会移除异步缓存功能

最佳实践建议

对于生产环境使用MyBatis-Plus多租户功能的开发者，建议：

1. 避免在关键业务场景使用异步缓存功能
2. 定期关注MyBatis-Plus的版本更新
3. 在升级版本前，充分测试多租户功能
4. 对于性能要求高的场景，可以考虑其他缓存策略

总结

MyBatis-Plus作为优秀的ORM框架，其多租户功能为SaaS应用开发提供了极大便利。但在使用高级特性如异步缓存时，开发者需要充分了解其实现原理和潜在风险。通过这个案例，我们再次认识到在框架使用过程中平衡性能与稳定性的重要性。