MySql单表最大8000W+ 之数据库遇瓶颈记

Posted 2021-03-23 lonelyxmas

原文:MySql单表最大8000W+ 之数据库遇瓶颈记

前言

昨晚救火到两三点，早上七点多醒来，朦胧中醒来发现电脑还开着，赶紧爬起来看昨晚执行的SQL命令结果。由于昨晚升级了阿里云的RDS，等了将近两个小时 还在 升降级中，早上阿里云那边回复升级过程中出现异常，正在加紧处理。。。有点蛋疼

 

项目介绍

这个项目主要分为WEB、WEB-Manager、WEB-API、APP（android、ios） 。

开发语言主要是ASP.NET 

数据库mysql

架构采用了ASP.NET +EF+ORM   Unity依赖注入 采用了DDD的部分实践 

ORM使用的是AutoMapper

使用了Redis缓存

Log4net记录文件日志，刚开始使用Mongodb记录日志，用了一段时候后取消了。

WEB端使用了angularjs    

API层通过JSON数据与APP进行交互，用户状态通过access_token进行传递

数据库层目前是基于仓储（Repositor）模式实现的

刚开始项目急于上线多数采用Linq +lambda 的查询方式，在实践过程中发现变态的业务调整和快速的请求响应，将其复杂的查询改成了原生SQL，通过Context.DataBase.SqlQuery  执行

 

其他的技术就不一一介绍了

目前访问量较大的是APP端， 最大并发 1300+

主要是API的压力比较大，日均 100W+ 请求，API 目前 部署在Windwos server 2012上，  接口在50个以上

数据库使用的是阿里云的单机MySql  RDS 5.6 版本，10盒12G，连接数2000，iops 6000  

目前 单表最大是8000W+数据。物理文件300G，APIlog日均100W+，API与业务系统完全独立，除了DBLog日志还有Log4g.net生成的文件日志。

目前采用的是阿里云的负载，一主一从  购买的阿里云负载      两台应用均为 8盒16G ，10M带宽 ，资源文件上了CDN。

主的上面部署了WEB端和WEB管理后台，从的上面只有API。

数据库遇瓶颈

        最近用户量突破10+以上，最大并发1300+  从前天晚上开始数据库CPU居高不下，一时达到100%临界点，导致很多SQL命令执行发生错误，链接拒绝。阿里云的报警短信也随之而来，随即我停掉了IIS应用，因为不停止应用MySql数据库很难复苏，大概过了5分钟之后数据库恢复正常，然后再开启IIS应用。蛋疼的是阿里云的负载健康检查也提示异常，但有点不解的是健康状态显示异常，请求仍然在继续分发，很是不解。立马我将IIS 应用程序池资源回收，停止然后再重启，这里给个提示  重启IIS应用程序池的时候最好先停止掉IIS应用，然后再重启IIS应用程序池，不然访问量大的情况下很难起起来。过了几分钟之后负载上的健康检查显示正常。

       上阿里云后来看了下各个监控指标，显示流量从前一个小时开始 突然猛增，我以为是有攻击，但跟踪了几个连接发现是正常请求，但360的防御助手显示确实有几个攻击，但那几个请求根本不足以拉跨数据库，大概也就几十个请求，   几个简单的  XSS攻击 这里贴下：攻击的数量不是太多，但主要攻击的内容和参数就这个几种类型

url/'%22/%3E%3C/script%3E%3Cscript%3Ealert()%3C/script%3E
url/'%22+onmouseover=alert()+d='%22

url/matrix_callback.php    

url/index.php?option=com_fields&view=fields&layout=modal&list%5Bfullordering%5D=updatexml(0x3a,concat(1,md5(233)),1)

后来发现是数据库遇到危机了，CPU几度达到了100%，活跃连接数和非活跃连接数都比平时都要高很多。目前数据库中有一张最大的表超8000W条数据，超300W以上的也有十几张，是查询拖垮了数据库，平时开发的时候我们都是要求查询类的SQL要求0.03秒之内完成。但涉及到这几张大表的查询我们设定到0.5秒之内返回。今天肯定是查过0.5秒了，

我查了下阿里云控制台的慢SQL日志，眼下系统运行还稍微正常，就拿那些慢SQL 一个一个的优化，不能立马发版，也就是不能改写SQL代码，只能从索引上进行优化了。就这样把慢SQL逐一过了一遍，大约有20多个  超2秒执行的，最慢的达到了10秒，最大的解析行数达到了10W行以上，哎 应该是下面的兄弟写sql不严谨，否则不会出现解析行数超10W+的，但兄弟挖的坑 我哭着也要去填。就这样用explain 调整索引的方式逐一过了一遍，之前通过表空间已经做过一次优化了。

到昨晚又到了高并发的时候，数据库又报警了，还好只是报警没有给我crash掉。与客户那边沟通下来，决定进行数据库扩容。现在扩容到了16盒64G 连接数14000 iops16000。

增加了一个应用几点，现在是一主两从

应该能撑一段时间了

 

接下来需要着手上读写分离， 针对比较大的表进行拆分，代码和数据库继续优化。尽量做到最优。

再下来着手上分布式   因为架构的演变是根据市场营销情况而定，不能走太前更不能走到市场的后面

周末比较累 写的比较简短，有时间再续