Open cjuexuan opened 6 years ago
今天小伙伴用xql的web版在操作mysql数据的时候,告诉我半天出不来数据,于是进行了一些debug
当时加了一些信息,因为那张表大概7kw左右,所以用户指定了要走jdbc的lowerBound和upperBound,所以我们会按照用户的条件和partition column求这两个值
lowerBound
upperBound
sql如下:
SELECT max($partColumn), min($partColumn) FROM $table $whereClause
但是我们发现很久没结果,于是打了下driver的线程
com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:173) => holding Monitor(com.mysql.jdbc.util.ReadAheadInputStream@259674710}) com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2954) com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3375) com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3365) com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3805) com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2478) com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2625) com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2551) => holding Monitor(com.mysql.jdbc.JDBC4Connection@1945604989}) com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1861) => holding Monitor(com.mysql.jdbc.JDBC4Connection@1945604989}) com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1962) => holding Monitor(com.mysql.jdbc.JDBC4Connection@1945604989}) com.ximalaya.xql.engine.jdbc.JDBCLoadPartitionConnection.calculateMaxMinBound(JDBCLoadPartitionConnection.scala:28) com.ximalaya.xql.engine.interpreter.jdbc.JdbcInterpreter.com$ximalaya$xql$engine$interpreter$jdbc$JdbcInterpreter$$getJDBCPartition(JdbcInterpreter.scala:199)
发现卡在了com.mysql.jdbc.PreparedStatement.executeQuery这里
com.mysql.jdbc.PreparedStatement.executeQuery
于是我们决定去db看下我们的执行情况
我们发现真的没有命中索引,所以慢也自然而然很正常了,试了下直接执行这个查询,是需要几分钟时间的
突然想了下,要不拿主库试下,于是去主库试了下
发现主库的explain是走了我们的索引的,于是运行了下我们的查询,大概在10s内完成了
于是我们把这个datasource加到xql中,试了下我们代码,果然一切正常,看来锅还是index的,于是对比了下两个的index info
发现果然Cardinality的锅,啥也别说,ANALYZE下表吧:(
楼主,请问下,你那个spark on client 用ide工具debug的代码能分享下吗?谢谢了,或者教我下怎么弄的也可以,感激不尽
@xiashuijun 设置下spark.master为yarn,设置下spark.submit.deployMode为client,在触发的代码里反射调用driver的main函数,就可以了
@cjuexuan 谢谢了
问题描述
今天小伙伴用xql的web版在操作mysql数据的时候,告诉我半天出不来数据,于是进行了一些debug
初步定位
当时加了一些信息,因为那张表大概7kw左右,所以用户指定了要走jdbc的
lowerBound
和upperBound
,所以我们会按照用户的条件和partition column求这两个值sql如下:
SELECT max($partColumn), min($partColumn) FROM $table $whereClause
但是我们发现很久没结果,于是打了下driver的线程
发现卡在了
com.mysql.jdbc.PreparedStatement.executeQuery
这里从库DEBUG
于是我们决定去db看下我们的执行情况
我们发现真的没有命中索引,所以慢也自然而然很正常了,试了下直接执行这个查询,是需要几分钟时间的
主库DEBUG
突然想了下,要不拿主库试下,于是去主库试了下
发现主库的explain是走了我们的索引的,于是运行了下我们的查询,大概在10s内完成了
进一步分析
于是我们把这个datasource加到xql中,试了下我们代码,果然一切正常,看来锅还是index的,于是对比了下两个的index info
发现果然Cardinality的锅,啥也别说,ANALYZE下表吧:(