mybatis 打印Preparing ： sql select ............. where id = ?时，是已经获得了连接还是没有拿连接

[jin9521]

下边是日志，发现到准备sql时卡了16分钟。

[tianfang]

还是上相关代码吧

结果集有多少行

[jin9521]

引用 2 楼 tianfang 的回复:

还是上相关代码吧

结果集有多少行

public List<String> getRoleByUserxh(String userxh) {
logger.debug("[+]getRoleByUserxh userxh={}",userxh);
SPUserRoleExample example1 = new SPUserRoleExample();
example1.createCriteria().andUserxhEqualTo(userxh);
List<SPUserRole> list2 = userRoleMapper.selectByExample(example1);
List<String> rolecodes = new ArrayList<String>();
for(SPUserRole uo : list2){
rolecodes.add(uo.getRolecode());
}
logger.debug("[+]getRoleByUserxh rolecodes={}",JsonUtil.getJsonString(rolecodes));
return rolecodes;
}

[jin9521]

引用 2 楼 tianfang 的回复:

还是上相关代码吧

结果集有多少行

结果集6条

[安优小青和他的程序生活]

在代码的前和后 加上输出时间耗费的语句，看看是哪一行代码耗费了16分钟。
话说 16分钟。。。。。。

[tianfang]

你圈的两个log记录不是一个过程中的吧。

至少不是Preparing
Preparing只用了1ms，就是你圈的第二条和后面一条

[亲爱的Joe]

分明是查询时耗费了16分钟，所以应该是拿到了。
16分钟啊......

[stacksoverflow]

连接时在进入service的时候拿到的。
把连接池的配置贴上来。
进入service：OrgService.getRoleByUserxh()到查询发出前的业务代码贴上来，是这块比较慢。

[jin9521]

引用 5 楼 tianfang 的回复:

你圈的两个log记录不是一个过程中的吧。

至少不是Preparing
Preparing只用了1ms，就是你圈的第二条和后面一条

是一个，同一个线程号。

[jin9521]

引用 6 楼 stacksoverflow 的回复:

连接时在进入service的时候拿到的。
把连接池的配置贴上来。
进入service：OrgService.getRoleByUserxh()到查询发出前的业务代码贴上来，是这块比较慢。

连接池配置
<bean id="ds_org" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close">
<property name="url" value="${jdbc_url_org}" />
<property name="username" value="${jdbc_username_org}" />
<property name="password" value="${jdbc_password_org}" />
<!-- 配置初始化大小、最小、最大 -->
<property name="initialSize" value="30" />
<property name="minIdle" value="30" />
<property name="maxActive" value="200" />
<!-- 获取连接最大等待时间 -->
<property name="maxWait" value="60000" />
<!-- 打开PSCache，并且指定每个连接上PSCache的大小 -->
<property name="poolPreparedStatements" value="true" />
<property name="maxPoolPreparedStatementPerConnectionSize" value="20" />
<!-- 配置间隔多久才进行一次检测，检测需要关闭的空闲连接，单位是毫秒 -->
<property name="timeBetweenEvictionRunsMillis" value="60000" />
<!-- 配置一个连接在池中最小生存的时间，单位是毫秒 -->
<property name="minEvictableIdleTimeMillis" value="300000" />
<!-- 数据库连接测试 -->
<property name="validationQuery" value="SELECT 'x' FROM DUAL" />
<property name="testOnBorrow" value="false" />
<property name="testOnReturn" value="false" />
<property name="testWhileIdle" value="true" />

<!-- 打开removeAbandoned功能 -->
<property name="removeAbandoned" value="true" />
<!-- 600秒，也就是10分钟 -->
<property name="removeAbandonedTimeout" value="600" />
<!-- 关闭abanded连接时输出错误日志 -->
<property name="logAbandoned" value="true" />
<!-- 监控数据库 -->
<!-- <property name="filters" value="stat" /> -->
<property name="filters" value="mergeStat" />

<!-- Druid连接池自定义数据库密码加解密 -->
<property name="passwordCallback" ref="dborgPasswordCallback"/>
<property name="proxyFilters">
<list>
<ref bean="statOrgFilter"/>
</list>
</property>

</bean>

[jin9521]

引用 6 楼 stacksoverflow 的回复:

连接时在进入service的时候拿到的。
把连接池的配置贴上来。
进入service：OrgService.getRoleByUserxh()到查询发出前的业务代码贴上来，是这块比较慢。

这个是OrgService里执行的方法，他之前没慢，圈红的第一条的时间就是这个方法的第一行。
public List<String> getRoleByUserxh(String userxh) {
logger.debug("[+]getRoleByUserxh userxh={}",userxh);
SPUserRoleExample example1 = new SPUserRoleExample();
example1.createCriteria().andUserxhEqualTo(userxh);
List<SPUserRole> list2 = userRoleMapper.selectByExample(example1);
List<String> rolecodes = new ArrayList<String>();
for(SPUserRole uo : list2){
rolecodes.add(uo.getRolecode());
}
logger.debug("[+]getRoleByUserxh rolecodes={}",JsonUtil.getJsonString(rolecodes));
return rolecodes;
}

[stacksoverflow]

看不出什么问题，如果service没有配置AOP的其他业务的话，应该是获取连接的时候比较慢，druid是提供强大的监控功能吧？把监控打开看一下连接池有没有异常。

[能源恒观]

你先分析一下你的sql 执行时间多少

[Vito1993]

数据表索引？

[jin9521]

引用 13 楼 qq_25219331 的回复:

数据表索引？

索引有的，而且查询速度特别快，问题不在sql

[hugaosu]

我想问一下，你那个红色的数字，是如何做到自定义配置的。我目前也需要实现这个需求