听说关注我的人，都实现了财富自由！你还在等什么？赶紧加入我们，一起走向人生巅峰！

SpringBootMyBatis配置打印SQL日志的两种方式及区别

MyBatis Plus 打印 SQL 日志之我见：是偷懒利器还是定位神器？

深夜，程序员小王还在苦逼地调试代码。线上环境突然出现了一个诡异的 Bug，数据库里的数据莫名其妙地少了！小王怀疑是 SQL 语句出了问题，但是茫茫代码，如何才能快速定位到出错的 SQL 呢？

一、一场关于打印 SQL 的“辩论”

小王打开常用的技术论坛，搜索“MyBatis Plus 打印 SQL”，映入眼帘的是一篇标题为“SpringBoot MyBatis 配置打印 SQL 日志的两种方式及区别”的文章。文章详细介绍了两种打印 SQL 日志的方法：

**方式一：**简单粗暴，直接使用 MyBatis Plus 提供的默认配置，所有 SQL 语句和执行结果都会打印到控制台。

**方式二：**精确定位，通过配置日志级别，只打印指定 Mapper 类中的 SQL 语句。

文章作者显然是“方式二”的拥趸，认为这种方法能够快速定位问题，是开发调试的利器。但评论区却炸开了锅，有人支持方式一的简单直接，也有人提出了其他的解决方案。

二、是“全面监控”还是“精准打击”？

这场关于打印 SQL 日志的“辩论”其实反映了开发者在调试过程中的两种不同需求：

**全面监控：**希望看到所有执行的 SQL 语句，方便排查问题。这种需求在开发初期或者进行大规模代码重构时尤为常见。

**精准打击：**只想关注特定模块或者功能的 SQL 语句，避免信息过载，提高调试效率。

方式一

就像是在数据库入口安装了一个监控摄像头，所有进出的 SQL 语句都会被记录下来。这种方法简单粗暴，但缺点也很明显：

信息过载：

当系统复杂度较高，SQL 语句调用频繁时，控制台会像瀑布一样刷过大量信息，难以找到真正有用的信息。

性能损耗：

打印 SQL 语句和结果会占用一定的系统资源，尤其是在高并发场景下，可能会对系统性能造成一定影响。

方式二

则更像是一个经验老道的侦探，通过分析案情，锁定目标，最终精准出击。这种方法能够有效避免信息过载，提高调试效率，但也有一定的局限性：

配置繁琐：

需要手动指定需要打印 SQL 语句的 Mapper 类，当项目较大，Mapper 类较多时，配置工作会变得比较繁琐。

不够灵活：

当需要调整打印的 SQL 语句范围时，需要修改配置文件并重启应用。

三、没有最好的，只有最合适的

究竟哪种方式才是打印 SQL 日志的最佳选择呢？

答案是：没有最好的，只有最合适的！

在实际开发中，我们需要根据项目的具体情况和个人开发习惯选择合适的打印 SQL 日志的方式。

对于简单的项目或者开发初期，可以使用方式一快速排查问题。

对于复杂的项目或者需要精准定位问题时，建议使用方式二，并结合一些日志工具和技巧，例如使用 AOP 切面拦截 SQL 语句、自定义日志格式等，进一步提高调试效率。

除了打印 SQL 日志之外，我们还可以借助其他工具和手段来排查数据库相关问题，例如使用数据库监控工具、SQL 性能分析工具等。

我想说的是，打印 SQL 日志只是解决问题的 means to an end。更重要的是，我们要养成良好的编码习惯，编写高质量的 SQL 语句，从源头上减少问题的发生。

你平时是如何打印 SQL 日志的呢？欢迎在评论区分享你的经验和看法！

本文旨在传递正能量，弘扬社会主旋律，无任何不良引导。如有侵权，请联系我们，我们将立即更正或删除。