Groovy中的sql.rows()运行缓慢

Question

我正在支持Grails Web应用程序,该应用程序使用AmCharts为客户端显示不同的视觉效果.在其中一个选项卡上有三个图表,每个图表根据不同的度量从数据库中返回前十个,因此只有十行.完成需要4-5次甚至更长时间.查询在10秒内在DB上运行.

调用以下服务方法以返回结果:

List fetchTopPages(params, Map querySettings, String orderClause) {
    if(!((params['country'] && params['country'].size() > 0) || (params['brand'] && params['brand'].size() > 0) || (params['url'] && params['url'].size() > 0))) {
        throw new RuntimeException('Filters country or brand or url not selected.')
    }
    Sql sql = new Sql(dataSource)
    sql.withStatement { stmt -> stmt.fetchSize = 100 }
    Map filterParams = acquisitionService.getDateFilters(params, querySettings)
    ParamUtils.addWhereArgs(params, filterParams)
    String query = "This is where the query is"

    ParamUtils.saveQueryInRequest(ParamUtils.prettyPrintQuery(query, filterParams))
    log.debug("engagement pageviews-by-source query: " + ParamUtils.prettyPrintQuery(query, filterParams))
    List rows = sql.rows(query, filterParams)
    rows

}

经过一些调查后,显然该List rows = sql.rows(query, filterParams)线路占用了这个加载时间.

有没有人在此之前表达过这个问题？为什么sql.rows()只返回10行结果,并且查询在DB端运行超快？

附加信息:

DB:FSL1D

在DB端运行以下命令:java -jar ojdbc5.jar - getversion返回:"在Thu_Jul_11_15上使用JDK5编译的Oracle 11.2.0.3.0 JDBC 3.0:41:55_PDT_2013默认连接属性资源Wed Dec 16 08:18:32 EST 2015"

Groovy版本:2.3.7 Grails版本:2.4.41 JDK:1.7.0

Answer 1

我的设置Groovy Version: 2.3.6 JVM: 1.8.0_11 和Oracle 12.1.0.2.0使用驱动程序ojdbc7.jar

请注意在运行之前激活10046 跟踪以允许诊断。

import oracle.jdbc.pool.OracleDataSource

def ods = new OracleDataSource();
ods.setURL('url')
ods.setUser('usr')
ods.setPassword('pwd')

def con = ods.getConnection()
def sql = new groovy.sql.Sql(con)
sql.withStatement { stmt -> stmt.fetchSize = 100 }
def SQL_QUERY = """select id, col1  from table1 order by id"""
def offset = 150
def maxRows = 20
// activate trace 10046
con.createStatement().execute "alter session set events '10046 trace name context forever, level 12'"

def t = System.currentTimeMillis()
def rows = sql.rows(SQL_QUERY, offset, maxRows)
println "time1 : ${System.currentTimeMillis()-t} with offset ${offset} and maxRows ${maxRows}"

对跟踪的检查显示该语句已被解析并执行，这意味着如果存在 ORDER BY 子句，则所有数据都已排序。

提取大小使用正确，并且提取的记录不超过所需的记录 - 此处 170 = 150 + 20。如果提取大小为 100，则分两步完成（注意参数r- 提取的行数）。

FETCH #627590664:c=0,e=155,p=0,cr=5,cu=0,mis=0,r=100,dep=0,og=1,plh=1169613780,tim=3898349818398
FETCH #627590664:c=0,e=46,p=0,cr=0,cu=0,mis=0,r=70,dep=0,og=1,plh=1169613780,tim=3898349851458

所以基本上我看到的唯一问题是“跳过”的数据通过网络传递到客户端（在那里被忽略）。

这可能会产生非常高的偏移量和大量开销（并且以交互方式运行相同的查询来生成第一页需要更多时间）。

但识别问题的最佳方法很简单，即启用 10046 跟踪并查看发生了什么。我使用的是 级别 12 ，这意味着您还可以获得有关数据库中等待和绑定变量的信息。