使用阿里云DRDS数据库做分库分表中遇到的问题分析记录

基于阿里云DRDS数据库问题分析记录

线上反应接口响应速度太慢，由此展开排查。通过执行时间定位很快定位到一个执行时间很长到慢SQL。该SQL基于阿里云DRDS做到分库分表调用。这里整理一篇文章记录下整个追踪调试到全过程，希望可以给后面的服务端优化工作一点参考。

首先定位到慢SQL如下：

select * from kdgx_partner_charge_notive 
    where uid = ? and type in (?, ?) 
  order by create_at desc 
  limit 1;
  
select count(*) from kdgx_partner_charge_notive 
    where uid = ? and is_read = 0 and type in (?, ?) 

查看表结构

可以看到该表拥有如下索引:

1. uid 主键
2. create_at B+树

分库分表规则和拓扑

hash规则分表，分割键uid，分库数8个，分表数128个

分库公式为：(uid % 1024 / 128); 分表公式为: (uid % 1024)

查看各个物理数据库的历史累计读写次数和读写权重

这里可以看到一个非常可疑的问题，0号数据库的读写次数是其他库的38倍。据此怀疑很可能是:

1. 分库键或分库规则选择不合理，导致数据分配不均衡
2. 数据库存在热点键，方案流量不均衡

查看各个物理表容量和性能

由于数据太多，这里只截取了部分重要数据

这里可以看到，总数为93520.6875M,其中0号DB数据量为51895.125M占比55.49%,这里基本可以判断是0号数据库数据分配不均衡问题了，问题分析到这里基本已经算是抓住狐狸尾巴了，后面我们的分析主要集中解决一下几个问题：

1. 不均衡的数据在哪里？最好具体到表，越细粒度的定位越能帮助业务分析产生如此数据分布的原因，从而有针对的思考解决办法。
2. 数据分布的不均衡注定会导致负载的不均衡，现在主要考虑是否负载的不均衡全是数据分布造成，或者负载不均衡是否是造成慢SQL的原因?

继续往下分析数据，找到如下信息：

0号库0号表数据量为45777M占比48.95%这是mysql不能忍受的数据量，当在这个表查询数据时必然导致慢SQL
的产生，慢SQL又会造成CPU和IO的繁忙，从而拖累整个数据库。
现在已经定位到数据库表了，根据上面我们找到的库表拓扑规则，可以大致定位到是哪个范围的分表键造成了这种现象。

结论

自此我们基本上已经排查到问题了，下面就要着手解决这两个问题，一般解决这种分布不均衡的方法分为两个纬度。

1. 数据库层进行分布再均衡。这种方法业务改动少、底层处理对上层屏蔽实现细节、实现更优雅，但是需要数据库支持。
2. 业务层自行处理。这个方法就不多说了懂的都懂。