Spring Boot+MyBatis SQL日志打印与排查实战指南-代码聚汇网

Spring Boot+MyBatis SQL日志打印与排查实战指南

半泽和莉娜·2026-09-04·阅读 67 GEO检测（免费）

Spring BootMyBatis-PlusSQL日志

|难度：普通|阅读约 35 分钟

先把一个高频场景摆出来：线上反馈某个列表查询结果不对，数据查不出来。代码走查了一遍，Service 层逻辑看着没问题，SQL 也拼接得挺像样，但就是不知道数据库到底收到了什么语句、参数传成什么样。这时候如果能立刻看到 MyBatis 帮我们生成的完整 SQL、绑定参数、返回行数，问题往往一眼就破。Spring Boot 项目里打印 SQL 日志和结果这件事，核心工具就两个方向：要么在 application.yml 或 application.properties 里用日志级别控制，要么引入一份自定义的 logback-spring.xml。两种方式各有边界，搞清楚了能少走很多弯路。

这篇文章不是简单丢一段配置就跑。我会把日志链路、Logger 名称规则、MyBatis-Plus 常见的 log-impl 坑、结果集打印的三种方案，以及“配置不生效”的真实排查流程都梳理一遍。适合刚接手 Spring Boot 项目但被 SQL 日志折腾过的人，也适合想把自己的日志体系从“能用”调到“好用”的开发者。

1. 先把链路讲透：SQL 日志不是 logback 自己造的，而是 ORM 上报的

1.1 Logger 名称与 Mapper 命名空间的对应关系

先理解一个容易被忽略的基础机制：Spring Boot 默认集成了 SLF4J + Logback，但你配置 logging.level 的时候并不是随便写一个包路径就生效，你配的 Logger 名称必须和“真正打印日志的那个 Logger 名称”一致。

MyBatis 在执行 Mapper 方法时，会为每一个 Mapper 接口或 XML 的 namespace 创建一个 Logger。假设你的 Mapper 接口是 com.example.demo.mapper.UserMapper，那这个 Logger 的名称基本就是 com.example.demo.mapper.UserMapper。你在配置文件里写：

yaml复制logging:
  level:
    com.example.demo.mapper: trace

其实是把 com.example.demo.mapper 这个 Logger 以及它下面的子 Logger 的级别调低了。MyBatis 执行 UserMapper.selectById 时，往 com.example.demo.mapper.UserMapper 这个 Logger 塞日志，继承了父级 com.example.demo.mapper 的 trace 级别，于是 SQL 就出来了。

XML 场景稍微注意一下，不管 Mapper 接口在哪个包，<mapper namespace="com.xxx.UserMapper"> 如果不与接口全限定名一致，日志名称跟着 namespace 走，和 Java 接口没直接关系。曾经遇到一个项目 XML namespace 写成了 com.xxx.mapper.UserMapper2，接口却是 UserMapper，开发在配置文件里盯了半天 UserMapper 的日志，实际打日志的是 UserMapper2，自然什么都看不到。这类基础问题占排查场景的一大半，但大多数人在配置层面翻来覆去找不到原因。

1.2 MyBatis-Plus、JdbcTemplate、JPA 的日志入口各不一样

很多人以为 SQL 日志是 Spring Boot 的统一能力，配一次就能通吃。其实不同数据访问层组件生成 SQL 日志的 Logger 名称、记录位置、输出内容完全不同。

数据访问层	实际打印 SQL 的 Logger	建议级别	特点
MyBatis / MyBatis-Plus	Mapper 接口全限定名，如 `com.example.demo.mapper.UserMapper`	trace 或 debug	trace 能看到返回行数据，debug 能看 SQL、参数、Total
Spring JDBC（JdbcTemplate / NamedParameterJdbcTemplate）	`org.springframework.jdbc.core.JdbcTemplate` 或 `JdbcTemplate$1`	debug	输出 executing prepared SQL statement、args 参数等
JPA / Hibernate	`org.hibernate.SQL` 和 `org.hibernate.orm.jdbc.bind`	debug / trace	SQL 与参数分开，新版 Hibernate 用 trace 才能看到绑定值
Druid 连接池	慢 SQL 日志是 Druid 自己的 Filter 机制，不归 logback 管	独立配置	建议用 stat filter 打印慢 SQL 统计

MySQL 驱动本身不打印 SQL，除非把 StatementLogger 等日志器打开，但那和业务代码隔得太远，日常排查一般不用。绝大多数项目用 MyBatis-Plus，所以下面第二章先讲它。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 最小改动：application.yml 里把日志级别调到 trace，SQL 参数和结果行就出现了

2.1 完整配置示例与每个 key 的作用

在 MyBatis-Plus 场景下，一份能立刻看到 SQL 的极简配置长这样：

yaml复制spring:
  application:
    name: demo

mybatis-plus:
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.slf4j.Slf4jImpl

logging:
  level:
    root: info
    com.example.demo.mapper: trace

这里最核心的两个点：

第一，logging.level.com.example.demo.mapper 调到 trace 或 debug。debug 级别下 MyBatis 会输出三行关键信息：

==> Preparing: 真正发送给数据库的 SQL 模板
==> Parameters: 绑定参数列表，能看出参数是不是为 null、类型是什么
<== Total: 本次更新或查询影响的行数

第二，mybatis-plus.configuration.log-impl 指定为 org.apache.ibatis.logging.slf4j.Slf4jImpl。这个配置的含义是：让 MyBatis 把日志交给 SLF4J，再由 SLF4J 路由到项目里的 Logback。如果不设置，MyBatis 会根据 classpath 自动选实现，多数 Spring Boot 项目会因为 classpath 里同时存在 SLF4J 而默认走 SLF4J，但有些老项目里会被别的实现抢先，导致 SQL 打到了标准输出而不是你配置的 logback 里。为了一致性和可预测性，建议显式写出来。

执行一个简单查询后，控制台大概长这样：

text复制2025-01-12 14:23:11.808 DEBUG 12345 --- [nio-8080-exec-1] c.e.demo.mapper.UserMapper              : ==>  Preparing: SELECT id,name,age,version FROM user WHERE id = ?
2025-01-12 14:23:11.809 DEBUG 12345 --- [nio-8080-exec-1] c.e.demo.mapper.UserMapper              : ==> Parameters: 1(Long)
2025-01-12 14:23:11.820 DEBUG 12345 --- [nio-8080-exec-1] c.e.demo.mapper.UserMapper              : <==      Total: 1

如果需求只是“我要看到 SQL 是不是发对了、参数有没有传对”，这三行已经足够了。

2.2 “log-impl = StdOutImpl” 会让日志绕过 logback，这是最常见的坑

网上很多教程会写：

yaml复制mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

配置完确实能在控制台看到 SQL，效果还挺明显。但是请注意，StdOutImpl 是直接把日志打到 System.out，本质上完全跳过了 SLF4J 和 Logback 的通路。结果就是：

无论你怎么调 logback-spring.xml，SQL 都不会进 sql.log 文件
logging.level 对它没作用，因为级别检查在 MyBatis 内部已经完成了
生产环境控制台输出会被 SQL 刷屏，而且没有文件留存，丢了就找不回来

我见过不止一个团队把 StdOutImpl 带到生产环境，排查问题时找不到历史 SQL 日志。踩过一次之后，我基本都改用 Slf4jImpl，让 SQL 日志纳入 logback 的统一管理和 Appender 策略中。这就是“配置文件方案”和“logback 方案”的真正分界点：如果你只是开发环境临时看一眼，StdOutImpl 无所谓；如果你希望日志体系统一、可留痕、可归档、可在文件里检索，就要走 SLF4J 通路。

2.3 不是 MyBatis：JdbcTemplate 和 Hibernate 的 SQL 日志怎么开

如果你的项目用的是 JdbcTemplate，那你的 Mapper 目录里没有 log-impl 这一说，直接用 logging.level 配 Spring 内部的 Logger 即可：

yaml复制logging:
  level:
    org.springframework.jdbc.core.JdbcTemplate: debug

输出内容里能看到 Executing prepared SQL statement 和 Executing prepared SQL statement [SELECT ...]，绑定参数会在另一行显示。实际测试时发现 org.springframework.jdbc.core 整个包打开 debug 会带出大量内部状态，所以建议精确到 JdbcTemplate。如果项目用 NamedParameterJdbcTemplate，它内部委托的是 JdbcTemplate，那层 Logger 同样会触发。

JPA / Hibernate 的场景更绕一些，老版本用：

yaml复制spring:
  jpa:
    show-sql: true

但这个 show-sql 同样是直接打到控制台或 stdout 的，不走 logback 文件。想要借助 logback 输出到文件，需要配 logger：

yaml复制logging:
  level:
    org.hibernate.SQL: debug
    org.hibernate.orm.jdbc.bind: trace

注意新版 Hibernate 6 之后，绑定参数的日志从 org.hibernate.type.descriptor.sql.BasicBinder 挪到了 org.hibernate.orm.jdbc.bind。很多老文章还在写 BasicBinder，新项目里配了无效。这类版本差异也是排查 SQL 日志不生效时的重要方向。

3. logback-spring.xml 是进阶形态：SQL 写独立文件、不同 Mapper 拆分文件、按环境开关

3.1 配置文件解决不了的三个诉求

光用 application.yml 有三大限制，遇到时就得考虑上 logback 配置文件了。

第一，日志要单独落盘。所有 SQL 日志和业务日志混在同一个 app.log 里，线上查一个问题，光日志就被其他服务的框架日志刷了几万行，定位效率太低。最好能把 SQL 日志写到一个 sql.log，按天滚动保存 60 天，和业务日志物理隔离。

第二，日志格式要控制。默认的 Spring Boot 控制台格式会包含线程、Logger 名称、PID 等字段。在一致性场景下没问题，但如果只想提取“时间、SQL、参数、行数”，默认格式就显得太啰嗦。自定义 logback 可以做到按业务场景定制输出格式。

第三，环境要区分。开发环境天天看 SQL 没问题，但测试联调、预发环境、生产环境希望自动关闭，或者只对某个特殊 Mapper 开 SQL 日志。application.yml 里当然也可以用 profile 文件去切，但用 logback 的 <springProfile> 更细腻，可以做到“同一个配置文件，不同环境不同行为”。

3.2 一份能直接落地的 logback-spring.xml：控制台保持干净，SQL 进独立文件

我这里给出一份在真实项目里常用过的配置骨架。它不是最简单的示例，而是把关键点都包进去了：

xml复制<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property name="LOG_HOME" value="${LOG_HOME:-./logs}" />
    <property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n" />

    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>${LOG_PATTERN}</pattern>
            <charset>UTF-8</charset>
        </encoder>
    </appender>

    <appender name="APP_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_HOME}/app.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_HOME}/app.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxFileSize>200MB</maxFileSize>
            <maxHistory>30</maxHistory>
            <totalSizeCap>20GB</totalSizeCap>
        </rollingPolicy>
        <encoder>
            <pattern>${LOG_PATTERN}</pattern>
            <charset>UTF-8</charset>
        </encoder>
    </appender>

    <appender name="SQL_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_HOME}/sql.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_HOME}/sql.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxFileSize>100MB</maxFileSize>
            <maxHistory>60</maxHistory>
            <totalSizeCap>10GB</totalSizeCap>
        </rollingPolicy>
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger{36} - %msg%n</pattern>
            <charset>UTF-8</charset>
        </encoder>
    </appender>

    <springProfile name="dev,test,staging">
        <logger name="com.example.demo.mapper" level="trace" additivity="false">
            <appender-ref ref="SQL_FILE" />
        </logger>
    </springProfile>

    <root level="info">
        <appender-ref ref="CONSOLE" />
        <appender-ref ref="APP_FILE" />
    </root>
</configuration>

这份配置的效果是：业务日志进 app.log，控制台打印 INFO 及以上；com.example.demo.mapper 这个 Logger 的 trace 日志只进入 sql.log，不会重复写进 app.log，也不会刷到控制台。

3.3 additivity=false 的取舍：不设的话日志会重复三遍

上面配置里 com.example.demo.mapper 被设置了 additivity="false"。这个属性值得单独解释。

additivity 默认是 true，意思是 Logger 打出来的日志除了进自己身上的 Appender，还会继续向上传递，交给父 Logger，最终可能进 root 的 Appender。如果不设置 additivity，配置里嵌套了 SQL_FILE Appender 和 CONSOLE Appender，那么 SQL 日志会同时出现在 sql.log、app.log、控制台三个地方。听起来无害，但生产环境 SQL 量大，等于多出两倍冗余 I/O，日志文件迅速膨胀。

加个 additivity="false"，SQL 日志就被圈死在 SQL_FILE Appender 里，既方便检索 SQL，又避免影响主链路日志。代价是 SQL 文件里的日志不会再出现在 app.log，这通常反而是我们想要的结果。

3.4 多个 Mapper 拆多个文件：logback 多文件写入的实现

热搜里有几个词很有代表性，logback java 多个日志文件写入 就是典型诉求：项目中订单 Mapper 和用户 Mapper 的 SQL 想分别写入 order-sql.log 和 user-sql.log，日志文件保持隔离。logback 完全支持，核心就是在不同的 Logger 上挂不同的 Appender：

xml复制<appender name="ORDER_SQL_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG_HOME}/order-sql.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
        <fileNamePattern>${LOG_HOME}/order-sql.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
        <maxFileSize>100MB</maxFileSize>
        <maxHistory>30</maxHistory>
    </rollingPolicy>
    <encoder>
        <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
    </encoder>
</appender>

<logger name="com.example.demo.mapper.OrderMapper" level="trace" additivity="false">
    <appender-ref ref="ORDER_SQL_FILE" />
</logger>

需要注意的地方是 Logger 名称一定要精确到具体 Mapper 接口。写 com.example.demo.mapper 会把整个包都打进去，想分文件就没法做。所以我一般建议：默认用包级别 logger 开 SQL 到总 sql.log，特殊希望重点观察的 Mapper 再加更精确的 logger，并且用 additivity="false" 阻断向上传递，这样就不会两个文件都出同一份 SQL。

3.5 springProfile 与异步打印的细节

配置里我用了 <springProfile name="dev,test,staging">。这个标签只能在 logback-spring.xml 里使用，如果文件名是 logback.xml，Spring Boot 不会解析 <springProfile>，启动时会直接报错或者把 profile 当成普通标签处理，功能失效。这一点容易被忽略：你把这段配置粘到 logback.xml 里，然后发现无论怎么切换环境 SQL 日志都不出来。

springProfile 的另一种用法是取反。比如某些团队希望生产环境也短暂开 SQL 日志查问题，但平时默认关掉，可以写成：

xml复制<springProfile name="prod">
    <logger name="com.example.demo.mapper" level="info" additivity="false">
        <appender-ref ref="SQL_FILE" />
    </logger>
</springProfile>

生产只保留 info，不给 trace，SQL 日志就处于关闭状态。等到排查问题需要明细时，可以通过 Spring Boot Actuator 动态把 logger 调高到 trace，不用重启应用。这个场景后面排查章节详细说。

还有一个常常被忽略的点：文件 Appender 默认是同步写，如果系统接口 QPS 高、SQL 日志量大，直接写文件可能拖慢响应。想优化可以引入 AsyncAppender：

xml复制<appender name="ASYNC_SQL" class="ch.qos.logback.core.AsyncAppender">
    <queueSize>2048</queueSize>
    <neverBlock>true</neverBlock>
    <discardingThreshold>0</discardingThreshold>
    <appender-ref ref="SQL_FILE" />
</appender>

但 neverBlock=true 意味着队列满的时候旧日志会被丢，追求不丢日志的场景要谨慎。日志系统从设计上就不是业务主链路的一部分，丢一小部分普通 SQL 日志对功能没有影响，但排查问题时发现缺了几条又很憋屈。我的取舍是：SQL 日志量一般可控，优先保证可见性，不轻易开异步，除非压测确认同步写文件影响到了接口耗时。

4. 配置不生效的排查链路：从 actuator/loggers 到日志实现覆盖

4.1 最常见的情况：明明照着配置做了，什么日志都没有

很多“配置文件不生效”的困惑，本质是对日志链路某个环节产生了误判。这里我总结一条适合照做的排查路径，按顺序来，不用急着怀疑框架坏了。

第一步，先搞清楚日志是否进入了预期的 Logger。Spring Boot 引入了 Actuator 后，可以直接查询任意 Logger 的生效级别：

bash复制curl http://localhost:8080/actuator/loggers/com.example.demo.mapper.UserMapper

响应大概是：

json复制{
  "configuredLevel": "TRACE",
  "effectiveLevel": "TRACE"
}

如果这里显示 effectiveLevel 是 INFO，说明你的 level 配置没有落到这个 Logger 上，那就先检查配置里的包名是否写对。如果这里显示 TRACE，但控制台和 sql.log 里都没有 SQL，问题就出在 MyBatis 的日志实现上，而不是 logback 配置上。

Actuator 还支持运行时动态修改日志级别，这个接口对排查问题非常有用，可以不用重启应用就把某个 Mapper 的日志临时调成 trace 再复原：

bash复制curl -X POST http://localhost:8080/actuator/loggers/com.example.demo.mapper \
  -H "Content-Type: application/json" \
  -d '{"configuredLevel": "TRACE"}'

4.2 Logger 名称对不上：比配置写错更隐蔽的几种情况

Logger 名称对不上是一个高频问题。举几个我实际遇到过的场景：

Mapper 接口在 com.example.demo.db.mapper，但 XML 文件里 namespace 写成了 com.example.demo.mapper，你在配置里写 com.example.demo.mapper，表面上覆盖了 namespace，SQL 确实会出来，但你如果按接口名去配就给错误印象。更麻烦的是同一个接口既用注解 SQL 又用 XML SQL，MyBatis 统一从 namespace 创建 Logger，只要 XML namespace 和接口不一致，注解 SQL 和 XML SQL 的日志名称反而不一样，排查时特别容易看漏。

Service 包下面包含 Mapper 实现类，有时项目启用了 AOP，通过 CGLIB 代理创建了 UserMapper$$EnhancerBySpringCGLIB$$...，但 MyBatis 的日志 Logger 名称依然取自 Mapper 自身，不会因为代理而改变。所以不用为了代理类去配置 $$Enhancer 这类名字。

MyBatis-Plus 的 BaseMapper 内置方法也有同样机制。你调 userMapper.selectList(null) 打印 SQL 的 Logger 名称就是 com.example.demo.mapper.UserMapper，和自定义 XML SQL 一模一样。

4.3 MyBatis 的 logImpl 被设置为 NoLoggingImpl，级别再对也没用

如果你的工程里明确设置了 mybatis-plus.configuration.log-impl 或 mybatis.configuration.log-impl，它被调成了 org.apache.ibatis.logging.nologging.NoLoggingImpl，那就等于 MyBatis 层主动关闭了所有 SQL 输出。这时 Application.yml 里的 logging.level 无论写 debug 还是 trace，都不会有任何 SQL 日志，因为 MyBatis 内部根本没创建真正的 Logger。

这个配置通常出现在项目里为了“关 SQL”而留下的全局设置。解决办法有几个：

删除或注释掉 log-impl 配置，交给 MyBatis 自动探测
显式改成 org.apache.ibatis.logging.slf4j.Slf4jImpl，保证输出进入 SLF4J
或者结合 springProfile 在开发环境用 Slf4jImpl，生产用 NoLoggingImpl

只改 logging.level 并不会改变 log-impl 的实际行为。这一点在排查问题时可以靠 MyBatis-Plus 的 SqlSessionFactory Bean 定义来验证，项目中自定义了 MybatisSqlSessionFactoryBean 且覆盖了 configuration，也要检查它是否 new 了一份 Configuration，且没有正确传递 log-impl。

4.4 application.yml 与 logback-spring.xml 同时配置级别时的优先级

项目里既写 logging.level.com.example.demo.mapper: trace，又在 logback-spring.xml 里写了同样的 Logger 配置，到底哪个生效？按照 Spring Boot 日志初始化的整体行为，环境变量里的 logging.level.* 一般会作为后置属性覆盖掉配置文件里的手动 level 设置，尤其是通过 LoggingSystem 在上下文中显式调用 setLogLevel 时。

为了避免这种混乱，我建议把配置职责分开：

logback-spring.xml 只负责 Appender、RollingPolicy、Pattern、logger 的 additivity 结构，里面尽量不写死 level
application.yml 只负责通过 logging.level.* 控制系统级别，因为它天然支持多 profile 文件和环境变量覆盖（如 ${SQL_LOG_LEVEL:info}）

这样不管是新同事还是接手项目的开发，看到配置时思路都是清晰的：日志输出到哪里找 logback，日志级别控制看 application.yml。两边不要重复定义同一个 logger，尤其是不要出现一处 debug、一处 trace 的不同数值。

5. “打印 SQL 结果”的几种选择：trace 日志、P6Spy、自定义日志出参

5.1 MyBatis trace 到底打出了什么

标题里写的是“打印 SQL 日志和结果”，很多人只看到了 SQL 语句，没意识到结果集的输出需要把 logger 级别从 debug 调到 trace。前面给的配置里我把 Mapper 级别设为了 trace，这正是为了看结果行。

在 trace 级别下，MyBatis 会额外输出查询结果集的列名和每一行的数据。执行 UserMapper.selectList 后，除了 Preparing、Parameters、Total，还有类似这几行：

text复制2025-01-12 14:23:11.813 TRACE ... <==    Columns: id, name, age, create_time
2025-01-12 14:23:11.814 TRACE ... <==        Row: 1, 张三, 25, 2025-01-01 10:00:00
2025-01-12 14:23:11.814 TRACE ... <==        Row: 2, 李四, 30, 2025-01-02 11:00:00
2025-01-12 14:23:11.814 DEBUG ... <==      Total: 2

这意味着“打印 SQL 结果”这件事，MyBatis 本身已经支持，未必需要引入额外组件。细节是 Row 的日志格式与 JDBC 驱动有关，有些驱动不会打印完整字段，只显示 Row: [Ljava.lang.Object;@...，这是类型转换层面的差异，不是配置错误。遇到这种情况，可以改用 P6Spy 或者自定义拦截器，把 Java 对象序列化成字符串。

另外注意 trace 会打印每一行结果，数据量大时日志体积可能翻成灾难级别。开发环境这么看没问题，生产环境务必谨慎。它适合联调阶段精确定位返回内容，不适合长期开着。

5.2 引入 P6Spy 的好处：看到 JDBC 层的完整执行信息和耗时

有些情况 MyBatis 的 trace 不够用：一是你用的不是 MyBatis 而是 JdbcTemplate，二是希望把耗时、连接 ID、返回行数一起放进日志里归档。P6Spy 是一个 JDBC 驱动代理层，它比 ORM 更接近数据库，能拦截到真正的 SQL 执行过程。

引入 P6Spy 的方式不复杂，pom 里加依赖：

xml复制<dependency>
    <groupId>p6spy</groupId>
    <artifactId>p6spy</artifactId>
    <version>3.9.1</version>
</dependency>

然后在数据源配置里，driver-class 替换成 P6Spy 驱动：

yaml复制spring:
  datasource:
    driver-class-name: com.p6spy.engine.spy.P6SpyDriver
    url: jdbc:p6spy:mysql://localhost:3306/demo?useUnicode=true&characterEncoding=utf8
    username: root
    password: root

再在 classpath 下放 spy.properties：

properties复制appender=com.p6spy.engine.spy.appender.Slf4JLogger
logMessageFormat=com.p6spy.engine.spy.appender.CustomLineFormat
customLogMessageFormat=%(currentTime)|%(executionTime)|%(sql)|%(resultSet)

配置里 slf4jLogger 会走 logback，%(executionTime) 能打印执行耗时，%(resultSet) 能看返回行数或结果提示。相比 MyBatis 自带的 trace，它能跨越 ORM 边界，对 MyBatis、JdbcTemplate、Hibernate 都生效，并且很容易把日志挂到你想要的 logback appender 中。

不过 P6Spy 并不适合所有项目。它给每个 SQL 都加了一层代理拦截，必然会有一点点性能损耗，线上核心链路不建议永久开启。我通常只在测试环境和大范围 LIN 问题排查时开，而且会用独立 profile 隔离。

5.3 自定义拦截器适合什么场景

如果既不想引入 P6Spy，又希望打印 Mapper 层参数对象的业务含义，可以考虑自定义 MyBatis 拦截器。不过这里有个分寸问题：MyBatis 拦截器的定位是扩展，不是日志工具。真正想把“参数对象 + 结果对象”按 JSON 输出，最好在设计好的 Service 边界、Repository 边界或者 AOP 切面里统一实现，而不是塞进拦截器里模拟。

我会给一个很克制的例子：通过拦截 StatementHandler.query，在 SQL 执行后输出 SQL 和结果行数，不把每条记录的完整内容都往日志里灌，避免踩到敏感字段，又能快速判断这个查询是不是真的落库了：

java复制@Component
@Intercepts({
        @Signature(
                type = StatementHandler.class,
                method = "query",
                args = {Statement.class, ResultHandler.class}
        )
})
public class SqlResultCountInterceptor implements Interceptor {

    private static final Logger log = LoggerFactory.getLogger(SqlResultCountInterceptor.class);

    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        StatementHandler handler = (StatementHandler) invocation.getTarget();
        BoundSql boundSql = handler.getBoundSql();
        String rawSql = boundSql.getSql().replaceAll("\\s+", " ").trim();
        long start = System.currentTimeMillis();
        Object result = invocation.proceed();
        long cost = System.currentTimeMillis() - start;

        int size = 0;
        if (result instanceof List) {
            size = ((List<?>) result).size();
        }
        log.info("sql={}, resultSize={}, cost={}ms", rawSql, size, cost);
        return result;
    }
}

这段拦截器也体现了“结果”的另一层含义：有时候你不需要每条数据内容，只需要知道返回了多少条、查询花了多久。把 SQL、结果行数、耗时作为一条结构化信息输出，比几千行 Row 日志更实用，也更容易做告警和慢 SQL 分析。

6. 把 SQL 日志收放自如：开发环境放开、生产环境闭嘴、重要时刻不漏

6.1 只显示重要日志，而不是把所有 Mapper 全部刷成 trace

“springboot+mybatis-plus 关闭sql数据输出，只显示重要日志”这个需求，本质是想在生产环境关掉 SQL 日志，但保留业务告警。最稳妥的做法不是把所有 logger 设为 OFF，而是用日志分组手段做一个明显分层。

Spring Boot 2.x 提供了 logging.group，可以把多个 Logger 归成一组，一次性控制：

yaml复制logging:
  group:
    biz: com.example.demo.service, com.example.demo.controller
    mapper-sql: com.example.demo.mapper
  level:
    root: warn
    biz: info
    mapper-sql: info

这里 mapper-sql 对应的 Mapper 包只在 info 级别，MyBatis 的 SQL 日志自然就关闭了，因为 SQL 输出基本发生在 debug/trace 级别。业务关键日志自己通过 Lombok 的 @Slf4j 写在对应 Service 类里，属于 biz 分组，保持 info 可见。这样一个配置就能把“SQL 噪音”和“真实业务日志”分开。

6.2 日志滚动策略与保留周期：不要一个文件写到磁盘爆炸

日志文件管理和打印 SQL 本身不是一件事，但实操时往往是连带的问题。很多人开了 SQL 日志以后不设置滚动，一个 sql.log 无限增长，最终把磁盘撑爆，然后被运维找上门。上面配置里我写了 SizeAndTimeBasedRollingPolicy，实际效果是按天和按大小双限制，超过单个文件大小自动切分，文件会保留 60 天：

maxFileSize：单个文件超过 100MB 就切
maxHistory：最多保留 60 个历史文件
totalSizeCap：所有日志文件总大小上限 10GB，防止 60 天累积