背景

每一年都进行大促前压测，每一次都须要再次关注到一些根底资源的应用问题，订单核心这边数据库比拟多，最近频繁报数据库异样，所以对数据库一些配置问题也进行了钻研，本文给出一些常见的数据库配置，阐明这些配置对咱们数据库应用的影响。目前，MySQL服务端配置对应用方来说是不可更改的，须要分割DBA进行操作。这些配置操作对咱们来说是一个黑盒，然而理解外围配置能够帮忙咱们疾速定位数据库问题起因。

问题汇总

问题一、too many connections

数据库服务端配置：max_connections
这个问题咱们这边线上遇到过，对于同一个数据库，有多个零碎都连贯了数据库，导致连贯数据库的机器比拟多，在数据库qps比拟大时，创立的连接数比拟大，导致连贯的总数超过了数据库服务端连贯的限度阈值，从而报了这个谬误。

举个栗子：如果max_connections设置为1000，咱们这边有200台机器，每台机器最大连接数为20，在连贯比拟大时，可能大抵连贯的总数为200 * 20 = 4000 > 1000，超过数据库的限度。

上面让咱们在本地演示一下这种谬误：

首先查问以后服务端最大连接数：

如果这个参数太大，不好演示的话，能够通过如下参数，将这个数值改小些

上面通过客户端尝试连贯数据库，能够看到，间接报错了

对于这种问题有两种解决办法：
第一种：分割DBA将max\_connections设置的大一些，DBA之前反馈max\_connections这个参数有主动增长的逻辑;
第二种办法：如果数据库操作qps并不是很大，能够将每台机器的数据库连贯最大值设置小一些，如果设置了初始化连贯大小，要思考机器数的增长，随着机器数的增长，连贯的总数必定会递增的。

问题二、慢日志长时间执行导致服务不可用

数据库库服务端配置：max\_execution\_time
之前写了一篇文章聊了一下如何在客户端配置参数解决慢日志长时间执行问题，这个在本地验证是没有问题的，然而因为咱们线上环境应用的是JED，JED的架构多了两头代理层，在客户端执行KILL QUERY CONNECTION_ID会提醒失败，导致没法进行慢sql（这个好坑，据说JED前期会优化这个问题）。

既然目前客户端没法管制慢sql进行，从官网上看了一下mysql服务端的配置参数，发现有一个参数可能管制服务端被动超时进行sql，参数变量：max\_execution\_time，本地环境验证如下：

首先将sql执行超时工夫设置为2s：

而后执行一个sleep函数，让执行工夫达到10s，能够看进去执行间接中断了，因为超过了2s的最大超时工夫：

问题三、服务端连贯都断开了，然而客户端还用有效连贯发送申请

数据库库服务端配置：wait_timeout
之火线上用的是mysql，通过mysql驱动包直连数据库，数据库服务端默认连贯闲暇工夫是8小时，起初响应公司号召，将传统的mysql切到了jed（底层也是mysql）, jed因为网关层的存在，客户端是通过mysql驱动包跟网关层进行直连，网关这一层数据库闲暇连贯超时工夫仅仅10分钟，过后在客户端进行闲暇连贯探活工夫超过10分钟，导致数据库报错频繁。当初曾经找不到历史的数据库异样日志了，本地模仿了一下，验证如下：

先将本地闲暇连贯超时设置为10s

验证源码如下，让两条sql执行工夫超过10s，能够发现第二次执行sql时执行报错了

所以，如果换了数据源，须要确认下服务端的闲暇连贯超时工夫设置，省得配置的值和客户端检测闲暇连贯衰弱性检测距离不匹配，呈现意料不到的后果。

注：咱们这边应用的是DBCP数据源连接池，配置如下：

<bean id="abstractParallelProductWriteDataSource" class="org.apache.commons.dbcp.BasicDataSource" abstract="true" destroy-method="close" init-method="createDataSource">        <property name="driverClassName" value="com.mysql.jdbc.Driver" />        <property name="username" value="${db.online.write.username}" />        <property name="password" value="${db.online.write.password}" />        <property name="initialSize" value="3" />        <property name="minIdle" value="3" /><!--最小链接数 -->        <property name="maxIdle" value="3" /><!--最大链接数 -->        <property name="maxActive" value="8" /><!--最大沉闷链接数 -->        <property name="maxWait" value="200" />        <property name="validationQuery" value="select 1" />        <property name="testOnBorrow" value="false" />        <property name="removeAbandonedTimeout" value="10" />        <property name="removeAbandoned" value="true" />        <!-- 池中的连贯闲暇10分钟后被回收,默认值就是30分钟 -->        <property name="minEvictableIdleTimeMillis" value="600000" />        <!-- 每5分钟运行一次闲暇连贯回收器 -->        <property name="timeBetweenEvictionRunsMillis" value="300000" />        <!--指明连贯是否被闲暇连贯回收器(如果有)进行测验.如果检测失败,则连贯将被从池中去除 -->        <property name="testWhileIdle" value="true"/>        <!--在每次闲暇连贯回收器线程(如果有)运行时查看的连贯数量，默认值是3 -->        <property name="numTestsPerEvictionRun" value="5"/>    </bean>

timeBetweenEvictionRunsMillis这个参数配置的是检测闲暇连贯的间隔时间，如果服务端闲暇连贯10分钟就断开了，这个工夫须要小于10分钟。minEvictableIdleTimeMillis这个工夫是判断以后连贯曾经闲暇了多久了，目前配置的是10分钟。

其余要害配置汇总

  1. thread_handling
    配置了服务端的线程解决模型，次要的值有no-threads、one-thread-per-connection、loaded-dynamically。其中no-threads示意同一时刻只能有一个连贯被一个线程解决。one-thread-per-connection示意对于每一个连贯申请都有一个线程来解决。loaded-dynamically是mysql的线程池模式，目前默认的是one-thread-per-connection，所以连贯太多的话，也会导致创立的线程疾速减少，耗费零碎的资源。
  2. slow\_query\_log
    用来管制是否打印慢日志，如果须要剖析零碎性能状况，能够关上这个开关，进行慢日志剖析。
  3. profiling
    是否启用sql查问性能剖析，相似于debug日志，线上环境须要敞开，比拟耗性能，这个参数前面mysql版本会废除掉，当初还是能够先应用着，新的应用形式能够参考：https://dev.mysql.com/doc/refman/8.0/en/performance-schema-query-profiling.html。

因为这个参数线上是敞开着，只能让DBA长期帮忙查问下剖析后果，平时也没咋用，感觉还是一个不错的工具，剖析后果相似上面截图：

总结

mysql服务端配置太多，目前工作中次要接触了上述这些配置，感觉还不错的，在平时剖析数据库问题上可能给予肯定的帮忙，大家也能够去多理解一下，更多的配置能够参考官网文档：mysql服务端配置官网

作者：京东批发 姜昌伟

起源：京东云开发者社区 转载请注明起源