共计 3415 个字符，预计需要花费 9 分钟才能阅读完成。
背景
每一年都进行大促前压测，每一次都须要再次关注到一些根底资源的应用问题，订单核心这边数据库比拟多，最近频繁报数据库异样，所以对数据库一些配置问题也进行了钻研，本文给出一些常见的数据库配置，阐明这些配置对咱们数据库应用的影响。目前，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 分钟。
其余要害配置汇总
- thread_handling
配置了服务端的线程解决模型，次要的值有 no-threads、one-thread-per-connection、loaded-dynamically。其中 no-threads 示意同一时刻只能有一个连贯被一个线程解决。one-thread-per-connection 示意对于每一个连贯申请都有一个线程来解决。loaded-dynamically 是 mysql 的线程池模式，目前默认的是 one-thread-per-connection，所以连贯太多的话，也会导致创立的线程疾速减少，耗费零碎的资源。 - slow\_query\_log
用来管制是否打印慢日志，如果须要剖析零碎性能状况，能够关上这个开关，进行慢日志剖析。 - profiling
是否启用 sql 查问性能剖析，相似于 debug 日志，线上环境须要敞开，比拟耗性能，这个参数前面 mysql 版本会废除掉，当初还是能够先应用着，新的应用形式能够参考：https://dev.mysql.com/doc/refman/8.0/en/performance-schema-query-profiling.html。
因为这个参数线上是敞开着，只能让 DBA 长期帮忙查问下剖析后果，平时也没咋用，感觉还是一个不错的工具，剖析后果相似上面截图：
总结
mysql 服务端配置太多，目前工作中次要接触了上述这些配置，感觉还不错的，在平时剖析数据库问题上可能给予肯定的帮忙，大家也能够去多理解一下，更多的配置能够参考官网文档：mysql 服务端配置官网
作者：京东批发 姜昌伟
起源：京东云开发者社区 转载请注明起源