后端编码规范系列（十五）开发环境/测试环境强制打印 sql

这里的要求也是我们在项目团队开发过程中逐步完善的，这是为什么呢?

这主要是来源于一次线上出现的问题，也就是有一条 sql 使用 in 查询的时候传值太多了，导致当时一条 sql 有好几十 M，然后就发生了内存OOM 的异常。这种问题也是比较难排查的，所以我们会在测试阶段着重核查一下这种 in相关的语句，在代码审核的时候也会要求对 in 的参数做相关的 size 校验。

在我们的日常开发和测试过程中，我们要求使用 p6spy 的框架。详情可参考本站的文章 ：《Mybatis plus应用（七）性能分析插件之p6spy》。

为什么选择这个框架呢？主要是因为：

1、这个框架可以很方便的检测出哪些 sql 执行时间过长，这个可能是由于 p6spy 框架的 bug 问题，sql 执行超过10秒就会抛出异常，所以在开发阶段配置 p6spy 的话我们可能很方便的提取慢 sql 进行优化。
2、这个框架可以打印出来每一条 sql 的执行时间，在进行 sql 优化的时候，我们可以根据执行时间进行筛选，例如筛选出执行时间超过3秒的 sql。大家可以想象一下，在开发和测试环境 sql 执行时间超过了3秒，那么在生产上由于数据量大的原因，执行时间是不是会更长，这种sql 是不是需要提前进行优化。
3、这个框架可以打印出来执行的每一条 sql 语句，包含执行的具体参数（这点比 mybatis plus打印的 sql 更完善，输出量也更少）。这里我们的 in 查询 bug 就是通过这个来发现的。

所以我们强烈建议大家在开发和测试阶段使用 p6spy 框架，便于提前发现问题，解决问题。避免在线上出现重大 bug。