log4j 配置 mybatis 怎么操作？log4j mybatis 配置教程

要实现Log4j对MyBatis的高效监控,核心在于精准配置log4j.properties（或XML）文件中的Logger级别，特别是针对MyBatis特有的包路径（如org.apache.ibatis和java.sql）进行分级控制，并结合Appender实现日志的分离存储。正确的配置不仅能打印出完整的SQL语句与参数，还能避免生产环境海量日志拖垮系统性能，这是保障系统可维护性与稳定性的关键一步。

核心配置原理：Logger与Appender的协同机制

Log4j与MyBatis的集成,本质上是通过Log4j捕获MyBatis运行时的日志事件，MyBatis在执行SQL、参数映射、结果集处理时，会调用底层日志框架，而Log4j作为最主流的实现之一，通过定义Logger（记录器）和Appender（输出端）来决定日志的输出内容与目的地。

Logger负责捕获信息，Appender负责输出信息。 在MyBatis场景下，最核心的需求是看到执行的SQL语句和传入的参数，这需要将java.sql包下的日志级别设置为DEBUG，如果仅仅设置Root Logger为DEBUG，虽然能看到SQL，但会输出大量无关的框架调试信息，导致日志文件迅速膨胀，甚至影响I/O性能。精细化控制不同包的日志级别是配置的核心策略。

实战配置步骤：从基础到精细化控制

在实际项目中,推荐使用log4j.properties进行配置，因其简洁直观，配置需遵循“定义输出格式 -> 定义输出目的地 -> 配置具体包级别”的顺序。

定义控制台输出Appender,便于开发阶段调试：
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n

配置MyBatis SQL输出，这是最关键的一步，必须单独配置java.sql包的日志级别：
log4j.logger.java.sql=DEBUG, stdout
这一行配置确保了所有JDBC相关的操作，包括Connection打开、SQL执行、参数设置都会被记录。注意，在生产环境中，应将此级别提升为INFO或WARN，避免敏感SQL信息泄露或性能损耗。

针对MyBatis框架自身的运行状态,如缓存命中、插件执行等，需配置：
log4j.logger.org.apache.ibatis=DEBUG, stdout
这有助于排查MyBatis内部的映射错误或插件冲突问题。

生产环境进阶：日志分级与文件滚动策略

在生产环境,单纯输出到控制台毫无意义，必须采用滚动文件策略。建议将SQL日志与业务系统日志分离存储，便于后期审计与性能分析。

定义一个专用于SQL的Appender：
log4j.appender.SQLFILE=org.apache.log4j.DailyRollingFileAppender
log4j.appender.SQLFILE.File=/var/log/myapp/sql.log
log4j.appender.SQLFILE.DatePattern='.'yyyy-MM-dd

将java.sql的日志输出指向该文件：
log4j.logger.java.sql=DEBUG, SQLFILE
这种“业务日志与SQL日志分离”的架构设计，极大提升了问题排查效率，运维人员无需在海量业务日志中翻找SQL语句，直接分析SQL日志文件即可定位慢查询。

酷番云实战案例：云环境下的日志聚合方案

在某大型电商客户迁移至酷番云高性能云服务器的项目中，初期客户反馈订单系统在高峰期响应迟钝，但应用层日志未报错，通过分析客户部署在酷番云云主机上的应用，我们发现其Log4j配置将所有日志混在一个文件中，且级别全开，导致单日日志量高达50GB，磁盘IO成为瓶颈。

我们协助客户进行了专项优化：

1. 日志分层：利用Log4j配置，将MyBatis的SQL日志单独输出至sql.log，业务日志输出至app.log。
2. 级别管控：生产环境将java.sql级别调整为INFO，仅在酷番云控制台开启“实时日志分析”功能时，动态开启DEBUG级别进行短时诊断。
3. 资源隔离：将日志存储路径挂载至酷番云高性能SSD云盘，避免日志写入抢占系统盘IO。

优化后,客户服务器磁盘IO利用率下降40%，且通过独立的SQL日志迅速定位到某几个慢查询SQL（未命中索引），经数据库优化后，系统吞吐量提升了25%。这一案例证明，优秀的Log4j配置必须结合云基础设施的存储特性，才能发挥最大效能。

常见陷阱与解决方案

在配置过程中,开发者常遇到“SQL打印不全”或“只打印问号”的问题，这通常是因为MyBatis使用了占位符，而Log4j默认只记录SQL语句本身，不记录参数替换结果。要解决此问题，必须确保java.sql.PreparedStatement类的日志级别为DEBUG，这样才能看到完整的参数设置过程。

另一个陷阱是日志冲突,如果项目中同时存在Log4j、Logback、Commons Logging等多个日志框架，可能会导致Log4j配置失效，此时需检查依赖树，使用<exclusion>标签排除冲突依赖，确保MyBatis绑定使用Log4j实现。

相关问答

为什么配置了Log4j，MyBatis的SQL语句依然没有打印出来？
解答： 这种情况通常由三个原因导致，检查MyBatis配置文件mybatis-config.xml中<settings>标签下的logImpl属性是否被强制指定为其他日志框架（如SLF4J），如果是，需改为LOG4J或留空自动探测，检查Log4j配置文件中java.sql包的日志级别是否设置为DEBUG，确认项目中是否存在日志门面冲突，如SLF4J绑定了Logback而非Log4j，导致Log4j配置被忽略。

生产环境中，开启MyBatis的DEBUG日志会对性能产生多大影响？
解答： 影响非常显著，开启DEBUG级别日志意味着每一次数据库交互都会触发磁盘I/O或网络I/O（如果日志中心化），在高并发场景下，频繁的日志写入会造成锁竞争，阻塞业务线程，同时日志文件的极速膨胀会耗尽磁盘空间。建议生产环境默认设置为INFO或ERROR级别，仅在排查特定问题时，通过Log4j的动态刷新功能或JMX接口临时开启DEBUG级别，排查完毕后立即关闭。