一条失去条件的动态 SQL，到手的年终奖飞了

哈喽，各位新来的小伙伴们，大家好！由于公众号做了改版，为了保证公众号的资源能准时推送到你手里，大家记得将咱们的公众号 加星标置顶 ，在此真诚的表示感谢~

正文如下：

# 前言

今天想跟大家聊聊一次 mybatis 动态 SQL 引发的生产事故。

事情这样的，我们有个订单相关数据库服务，专门负责订单相关的增删改查。这个服务运行了很久，一直都没有问题。

直到某天中午，正想躺下休息一下，就突然接到系统报警，大量订单创建失败。

订单服务可以说是核心服务，这个服务不可用，整个流程都会被卡主，交易都将会失败。

马上没了睡意，立刻起来登上生产运维机，查看订单服务的系统日志。

Caused by: java.util.concurrent.RejectedExecutionException: Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-xxip, Pool Size: 200 (active: 200, core: 200, max: 200, largest: 200), Task: 165633 (completed: 165433), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in 1!
        at com.alibaba.dubbo.common.threadpool.support.AbortPolicyWithReport.rejectedExecution(AbortPolicyWithReport.java:53)
        at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:768)
        at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:656)
        at com.alibaba.dubbo.remoting.transport.dispatcher.all.AllChannelHandler.caught(AllChannelHandler.java:65)

如上所示，日志中打印大量的 Dubbo 线程池线程耗尽，直接拒绝服务调用的日志登上另一台机器，好家伙，除了上述日志以外，仔细翻看居然还发生 「OOM」！

其实发生 「OOM」 了，问题倒是简单了，首先 「dump」 一下，然后分析一下生成的日志，查找内存占用最大类，然后分析定位具体代码块。

结合系统日志以及 dump 日志，我们很快就定位到发生问题的代码位置，样例代码如下：

Order order=new Order();
log.info("订单查询参数信息:{}",order);
// 其他系统逻辑,关键信息数据加密等
List<Order> orderList = orderMapper.query(order);
// .. 其他查询逻辑

查询底层使用 mybatis 动态 sql 功能，样例如下：

<select id="query" parameterType="order" resultMap="orderResultMap">
    select orderId,amt,orderInfo // 还有其他信息
    from
    Order
    <where>
        <if test="orderId != null">
            orderId = #{orderId}
        </if>
        <if test="amt != null">
            AND amt = #{amt}
        </if>
       ..... 其他条件
    </where>
</select>

上面的代码很简单，由于传入 mybatis 查询语句参数都未设置，从而导致生成的 sql 缺失了查询条件了，查询全表。

而由于订单表的数据非常多，全表查询返回的数据将会源源不断的加载到应用内存中，从而引发 「Full GC」，导致应用陷入长时间的 「stop the world」。

由于 Dubbo 线程也被暂停了，接收到正常的调用无法及时返回结果，从而引发服务消费者超时。

另一方面，由于应用不断接受请求，而大量 Dubbo 线程不能及时处理调用，从而导致 Dubbo 线程池中线程资源被耗尽，后续请求将会被直接拒绝。

最后最后，系统应用内存实在无法再加载任何数据，于是抛出上文中 「OOM」 异常。

问题本质原因是找到了，那为什么之前查询都没事，而这次突然就没传值了呢？

原来是因为前端页面改动，导致传入的查询参数为空！！！

前端页面迟迟不能显示查询的订单，用户一般会选择重试，然后又未传入查询参数，再一次加重应用的情况，雪上加霜。

# 扩展思考

上面的问题，我们只要重启应用，暂时还是能解决问题。想象一下如果使用动态 sql 发生在其他场景，会怎么样？

假设用户的余额表使用动态 sql 更新，这时如果条件丢失将会导致全部用户的余额都会发生了变化。如果是余额变多，那可能还好。但是如果余额是变少的，那真的很可能演变成社会事故了~

我们再假设下，如果某些配置表使用了动态 sql 物理删除数据，这时如果条件丢失将会导致全表数据被删。数据如果都没了，没什么好说了，跑路吧~

可以看到，更新/删除这类动态 sql，如果丢失了条件，那导致的危害将会很大，业务可能都会被停摆。

# 解决办法

那有没有什么办法解决这些问题？

「很简单，不要用动态 sql 了，直接手写吧~」

emm！你们先把刀放下，我开个玩笑的~

虽然上面的问题确实是动态 sql 引起的，但是本质原因我觉得还是使用不当引起的。

我们肯定不能因噎废食，自废武功，从此退回到「刀耕火种」时代，手写 sql。

好了，不说废话了，解决动态 sql 带来潜在的问题，我觉得可以从两方面下手：

第一、改变意识形态，科普动态 sql 可能引发的问题，让所有开发对这个问题引起重视。

只有当我们意识动态 sql 可能引发的问题，我们才有可能在开发过程去思考，这么写会不会被带来问题。

「这一点，我觉得真的很重要。」

第二，针对实际的业务场景提供可控的查询条件，并且对外接口一定要做好必要的参数校验。

我们要从实际的业务场景出发分析对外需要提供那些条件，原则上主库表必须按照主键或唯一键查询单条，或者使用相关的外键查询多条。比如说，订单表查询支付单号这类主键查询。

另外针对这些查询条件，接口层一定要做好的必要的参数校验。如果参数未传，直接打回，防患于未然。

如果真的有需要查询多条数据后台需求，这类查询不需要很高实时性，那么我们其实可以与上面应用查询剥离开来，并且查询使用从库。

第三，增加一些工具类预防插件。

比如我们可以在 mybatis 增加一个插件，检查执行的 sql 是否带有 where 关键字，若不存在直接拦截。

mybatis 拦截器如下：

@Intercepts({
        @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class,
                RowBounds.class, ResultHandler.class}),
        @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class,
                RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class}),
        @Signature(type = Executor.class, method = "update", args = {MappedStatement.class,
                Object.class})})
@Slf4j
public class CheckWhereInterceptor implements Interceptor {

    private static final String WHERE = "WHERE";

    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        //获取方法的第0个参数，也就是MappedStatement。@Signature注解中的args中的顺序
        MappedStatement mappedStatement = (MappedStatement) invocation.getArgs()[0];
        //获取sql命令操作类型
        SqlCommandType sqlCommandType = mappedStatement.getSqlCommandType();
        final Object[] queryArgs = invocation.getArgs();
        final Object parameter = queryArgs[1];
        BoundSql boundSql = mappedStatement.getBoundSql(parameter);
        String sql = boundSql.getSql();
        if (Objects.equals(SqlCommandType.DELETE, sqlCommandType)
                || Objects.equals(SqlCommandType.UPDATE, sqlCommandType)
                || Objects.equals(SqlCommandType.SELECT, sqlCommandType)) {
            //格式化sql
            sql = sql.replace("\n", "");
            if (!StringUtils.containsIgnoreCase(sql, WHERE)) {
                sql = sql.replace(" ", "");
                log.warn("SQL 语句没有where条件，禁止执行,sql为:{}", sql);
                throw new Exception("SQL语句中没有where条件");
            }
        }
        Object result = invocation.proceed();
        return result;
    }

    @Override
    public Object plugin(Object target) {
        return Plugin.wrap(target, this);
    }

    @Override
    public void setProperties(Properties properties) {

    }
}

上面的代码其实还是比较粗糙，各位可以根据各自的业务增加相应的预防措施。

# 小结

今天的文章，从真实的例子出发，引出了动态 sql 潜在的问题，主要想让大家意识到这方面的问题。从而在今后使用动态 sql 的过程中更加小心。

热门推荐：