​LongSql问题分析办法​

概述

• 在局点上线后，随着业务数据量的增大，我们经常会遇到dds longsql的问题。本文将从取日志，找业务代码，以及优化几个步骤分析如何解决该类问题。

---

取日志

• 找到该环境的ddsbackend节点的/home/log/dds/ddsbackend-O/profile/ 目录下取 longSql_ddsserver.plog日志，或者一般现网会发给我们该日志。在该日志中我们可以看到具体是哪条sql超时

---

找到业务代码

• 找到具体sql语句后接下来就要定位到具体的业务代码，是哪里调用了该sql语句。我们可以使用arthas工具追踪具体的调用栈，以下我们以OM_INVOKE_LOG表举个例子：

  • 由于我们之前在代码里搜到了该表的查询逻辑为定时任务触发，并且是在批量节点执行，所以直接去批量节点使用arthas追踪。正常场景如果不知道业务代码位置可以在各个节点都是用arthas追踪一下：

    • watch com.huawei.soa.bdf.component.beql.executor.impl.BeqlJdbcExecutor execute '#stack={},new Throwable().getStackTrace().{#it=#this,#stack.add(#it)},#stack=#stack.subList(24,#stack.size()),{returnObj,params,#stack}' 'params[0].getSql().contains("OM_INVOKE_LOG")' -x 2

      ​
  • 根据arthas的堆栈结果，我们便可已找到触发该sql的调用堆栈：

---

优化

• 接下来就到了最关键的步骤，优化。根据业务具体的使用场景我们可以从以下几个常见点去优化：
  • 取消排序：对大数据表进行排序是一个非常耗时的机制，如果具体的业务场景不需要用到排序场景，我们可以在sql中将排序取消掉。
  • 检查索引：索引是另外一个sql执行效率的重要因素，索引失效有以下常见几点原因：
    • 最常见的一种是缺少索引字段例如be_id，导致没有走联合索引。
    • 索引使用了函数，计算，或者类型转换。
    • 或者条件里使用了like查找特定后缀条件（%XX）（索引的机制是前缀匹配，大家可以去了解一下）
    • 条件里左右两边的类型不一致时，会发生隐式转换。左边是字符串时 ，会导致索引失效，因为"a100"和“100” 都会被转换成100的浮点数。
    • 还有一种常见的情况是索引本身不合理，比如建立索引的字段大部分数据都是一样的（例如be_id大部分都是101）。
  • 数据冷热分离或清理数据：最后我们还可以通过减少数据量的方式来优化，例如将大数据表定期移历史，或者没有历史表的直接只保留N个月的数据。
  • 还有一些类似的问题例如sql不下沉