阿里云数据库教程–云数据库RDS连接数过多的排除办法

通常情况下,Mysql的一个请求就会产生一个连接，阿里云数据库RDS存在最高连接数限制，根据实例性能不同，连接数上限也各不相同。当有请求（update、select、insert、delete）长时间执行，就会导致后续连接大量累计；出现连接数超限的情况，实例会拒绝新建连接，进而影响业务的正常运行。当用户收到连接数超限的短信提醒时，应由相关技术人员登录数据库按以下步骤进行排查，及时处理那些长时间执行的sql。避免出现业务访问被拒绝的情况。

问题排查步骤:

1. 查看实例配置：
   用户需要登录RDS控制台“详情与配置”查看实例的接数上限，这里假设最高支持1500个链接。
2. 查看当前的连接数：
   • 在RDS控制台“性能监控”可以查看实例的当前连接数。
   • 在客户端内执行以下SQL查看连接数
     mysql -uroot -h127.0.0.1 -P3020 -e “show processlist”|wc -l
1262
     从以上代码可见该实例已经有1262个连接
3. 排查是什么动作占用了这些连接:
   • 取出Mysql日志:
     myql -uroot -h127.0.0.1 -P3018 -e “show full processlist”>/tmp/1.log
   • 查看日志文件:
     more /tmp/1.log
   • 以下为我们的服务器上的一个案例日志:
     615083 my_db 223.4.49.212:54115 my_db Query 100 Sending data
INSERT INTO tmp_orders_modify (oid, tid, seller_id, status, gmt_create, gmt_modified)
SELECT oid, tid, seller_id, status, gmt_create, gmt_modified
FROM sys_info.orders WHERE
gmt_modified < NAME_CONST(‘v_last’,_binary’2012-12-24 10:33:00’ COLLATE ‘binary’) AN D gmt_modified >= NAME_CONST(‘v_curr’,_binary’2012-12-24 10:32:00’ COLLATE ‘binary’)
621564 my_db 223.4.49.212:46596 my_db Query 3890 sorting result
insert into tmp_trades(sid, d, h, tc, tm, tp, ic, new_tp, old_tp)
select a.seller_id as sid,
…………
from orders_1 as a where seller_id =1 and is_detail = ‘1’
and created < date_format(‘2012-12-24 10:35:00’, ‘%Y-%m-%d %H:00:00’)
and gmt_create < date_format(‘2012-12-24 10:40:00’, ‘%Y-%m-%d %H:%i:00’) and gmt_create >= date_format(‘2012-12-24 10:35:00’, ‘%Y-%m-%d%H:%i:00’)
group by d, h
order by d
     …………此处省略其他sql
4. 分析连接占用的原因：
   以上示例日志可知，实例内有SQL长时间未执行完毕，导致后续连接请求无法执行，进而产生大量的堆积；直至耗尽额定连接数。所以这个时候需要排查为什么这些sql 为什么长时间没有执行完毕，是索引没有创建好，还是sql执行耗时严重。
   • 第一条SQL语句:
     INSERT INTO tmp_orders_modify (oid, tid, seller_id, status, gmt_create, gmt_modified) SELECT oid, tid, seller_id, status, gmt_create, gmt_modified FROM sys_info.orders WHERE gmt_modified < NAME_CONST(‘v_last’,_binary’2012-12-24 10:33:00’ COLLATE ‘binary’) AND gmt_modified >= NAME_CONST(‘v_curr’,_binary’2012-12-24 10:32:00’ COLLATE ‘binary’)
     该语句是从从sys_info 数据库中拉取用户订单到自己的业务库中，但是在orders 表上没有gmt_modified 的索引，导致了全表扫描
   • 第二条SQL语句:
     看到这条sql 正在进行sorting 排序，为什么导致sql 长时间sorting，通常情况下为排序的结果集太大导致排序不能在内存中完成，需要到磁盘上排序，进而导致了性能的下降；解决的办法就是降低排序的结果集，常用的手段是利用索引的有序性，消除排序，或者建立适当的索引减小结果集；我们可以看到第二条sql 的排序字段非常的复杂，但是我们可以看到查询的时间范围是很短，只有5 分钟的时间间隔，这个时候就可以在gmt_create上创建一个索引，过滤掉大部分的记录：
     Alter tale order_1 add index ind_order_gmt_create(gmt_create)
     （该用户对orders 进行了分表，大概有50 多张分表需要添加gmt_create 字段的索引）；
5. 经过上面两步的优化后，用户实例恢复正常：
   io 情况和connection 情况，可再次登录RDS控制台查看连接数。