MyBatis-Plus多租户查询优化实践

多租户查询性能问题分析

在使用MyBatis-Plus 3.5.3.1版本进行多租户开发时，开发人员遇到了一个典型的查询性能问题。当主表数据量较大（3万条以上）时，使用LEFT JOIN结合ON条件进行多租户过滤的查询会出现超时现象。而将过滤条件移至WHERE子句后，查询性能则恢复正常。

问题现象重现

问题查询语句如下：

SELECT * FROM A 
LEFT JOIN B ON A.b_id = B.id AND B.tenant_id = -1 
LEFT JOIN C ON A.c_id = C.id AND C.tenant_id = -1 
WHERE 1=1 AND A.tenant_id = -1

优化后的查询语句：

SELECT * FROM A 
LEFT JOIN B ON A.b_id = B.id 
LEFT JOIN C ON A.c_id = C.id 
WHERE 1=1 AND A.tenant_id = -1 AND B.tenant_id = -1 AND C.tenant_id = -1

性能差异原因解析

这两种写法在PostgreSQL数据库中的执行计划存在显著差异：

1. JOIN条件过滤方式：

   • 第一种写法在JOIN操作时就应用了租户过滤条件
   • 第二种写法在完成JOIN后才应用过滤条件

2. 执行计划优化：

   • PostgreSQL优化器对WHERE子句中的条件优化更好
   • JOIN条件中的过滤可能无法有效利用索引

3. 数据过滤时机：

   • WHERE子句过滤发生在JOIN之后，但优化器可以智能地重写查询计划
   • ON条件过滤可能限制了优化器的选择空间

MyBatis-Plus多租户实现机制

MyBatis-Plus通过拦截器自动添加租户条件，其默认实现会将租户条件添加到WHERE子句中。这种设计考虑了以下因素：

1. 兼容性：WHERE子句过滤在大多数数据库中都表现良好
2. 可预测性：执行计划相对稳定，不易受数据分布影响
3. 索引利用：更容易利用租户ID字段上的索引

最佳实践建议

1. 查询写法：

   • 优先将租户条件放在WHERE子句中
   • 避免在JOIN的ON条件中添加额外过滤

2. 索引设计：

   • 为租户ID字段创建独立索引
   • 考虑创建复合索引(tenant_id, id)

3. MyBatis-Plus配置：

   • 保持默认的多租户SQL重写策略
   • 如需自定义，可继承TenantLineInnerInterceptor重写相关方法

4. 大数据量优化：

   • 考虑分页查询
   • 添加合适的查询条件缩小结果集
   • 对频繁查询的租户数据考虑缓存

总结

在MyBatis-Plus多租户应用中，查询性能优化需要综合考虑SQL写法、数据库特性和框架实现。通过理解不同查询写法的执行计划差异，开发人员可以避免类似性能问题，构建高效的多租户应用系统。