grails – Groovy中的sql.rows()运行缓慢
我正在支持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返回: Groovy版本:2.3.7 解决方法
我使用驱动程序ojdbc7.jar设置了Groovy版本:2.3.6 JVM:1.8.0_11和Oracle 12.1.0.2.0
请注意在运行之前激活10046 trace以允许诊断. 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}" 对跟踪的检查表明该stament被解析并执行,这意味着如果有ORDER BY子句,则对所有数据进行排序. 正确使用提取大小,并且只提取所需的记录 – 这里170 = 150 20. 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,cr=0,r=70,tim=3898349851458 所以基本上唯一的问题是我看到“跳过的”数据通过网络传递给客户端(在那里被忽略). 这可能会产生非常高的偏移量开销(并且需要更多时间来运行交互式生成第一页的相同查询). 但是,确定问题的最佳方法很简单,即启用10046跟踪并查看正在进行的操作.我正在使用 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |