[错误报告]: DataPermissionInterceptor repeatedly logs entire batch SQL under DEBUG, causing O(N²) log output

确认

• 我使用的版本是最新版, 并且使用插件确认过项目里无依赖版本冲突
• 我已经在 issue 中搜索过, 确认问题没有被提出过
• 我已经修改标题, 将标题中的 描述 替换为遇到的问题(不得删除 描述 前面的部分)

当前程序版本

3.5.14

问题描述

Problem

When DataPermissionInterceptor is enabled and the log level is set to DEBUG, executing batch SQL may generate an unexpectedly large amount of log output, even when no data permission rules are configured.

The interceptor still participates in SQL parsing and logging although it eventually decides to skip SQL modification.

This becomes especially noticeable when a batch consists of multiple individual SQL statements.

Reproduction

Suppose a batch execution contains N independent SQL statements, for example:

INSERT INTO table_a (...);

INSERT INTO table_a (...);

INSERT INTO table_a (...);

...

No data permission configuration is present.

Logging level:

logging.level.com.baomidou.mybatisplus=DEBUG Current Behavior

For each SQL statement, MyBatis-Plus prints:

Original SQL SQL before parsing SQL after parsing

However, during the "before parsing" phase, the interceptor logs the entire batch SQL, rather than only the current SQL statement.

As a result:

The complete batch SQL is printed once as the original SQL. During parsing, each of the N statements prints the entire batch SQL again. Each parsed SQL is then printed individually.

This leads to approximately O(N²) log output for a batch containing N SQL statements.

For large batches, the log volume grows dramatically.

Impact

This behavior causes several issues:

Extremely large DEBUG log files Significant redundant log output Increased disk I/O Reduced log readability Harder troubleshooting because useful information is buried in duplicated logs

Although this only occurs under DEBUG logging, it can seriously affect debugging sessions involving large batch operations.

Root Cause

DataPermissionInterceptor invokes SQL parsing for every SQL statement in the batch.

During DEBUG logging, the interceptor (or the underlying parser) logs the entire SQL script for each parsing operation instead of only the current statement.

Therefore, when a batch contains multiple SQL statements, the same SQL content is repeatedly printed, resulting in quadratic log growth.

Expected Behavior

The DEBUG log should ideally:

Log only the current SQL statement being parsed, or Print the complete batch SQL only once, avoiding repeated output of identical content.

This would significantly reduce duplicated logs while preserving the debugging information.

详细堆栈日志