活动期间MySQL稳定性保障思路

马上十一、中秋双节，很多客户开始做节日活动，基本都有一个共性需求：活动期间，流量预计翻N备，由此引发了一轮MySQL的容量治理与保障。

相对于Redis，功夫最好做在事前(参考 重大活动期间Redis稳定性保障思路-腾讯云开发者社区-腾讯云)，MySQL可以在事前和事中同时做一些事情，用好云平台的能力，往往会有意想不到的收获。

1、MySQL在业务架构中特点

相比于来自用户的高并发，MySQL往往会首先成为瓶颈，读写性能相对不足，所以MySQL前面一般都有缓存。

但Redis缓存被击穿后、业务流量突增导致写请求变多、未充分的压测等，都有可能导致MySQL的瓶颈暴露，最终导致整体业务的可用性受损。

2、事前治理思路

2.1 消除人为因素

可以考虑重大活动期间封网、控制可登陆生产数据库的权限，来尽可能避免人为对MySQL数据的影响。

2.2 容量

保障容量，主要考虑保障cpu/内存的冗余，用空间换时间；一方面要根据压测结果，做好扩容，另外一方面做好快速的弹性扩容及应急库容。可以考虑以下几个方面：

2.2.1 读写分离

单机的承载能力是有上限的，业界比较通用的方式是借助集群能力，读写分离，将读写请求分配到不同的设备，提升整体的承载能力。

一方面可以联系业务做好读写分离；另一方面可以借助腾讯云的能力，实现自动读写分离，还可以将十分耗资源的SQL路由到指定只读节点，避免影响整体业务流程。

自动读写分离参考下文：云数据库 MySQL 自动读写分离介绍-操作指南-文档中心-腾讯云

2.2.2 可写节点快速扩容能力

可以借助腾讯云的CPU弹性扩容能力，扩容MySQL实例的CPU。

CPU 弹性扩容-云数据库 MySQL-文档中心-腾讯云

2.2.3 只读节点的快速扩容能力

登陆控制台，找到制度节点，点击更多->调整配置，完成扩容

备注：如果需要扩容cpu和内存，采用TDSQL-C MySQL版的serverless 产品形态，参考文档： TDSQL-C MySQL 版 概述-Serverless 服务-文档中心-腾讯云

2.3 慢查询监控

这里主要的监控，是指把慢SQL给暴露出来。

操作步骤：

1. 登陆控制台，找到目标实例，进入详情

2. 切换到 数据库管理选项卡，点击参数设置，根据业务情况设置阈值。

2.4 消除慢SQL

慢SQL在高并发下，会阻塞整体请求，要消除慢SQL，可考虑的方式有：索引、SQL拆分、数据拆分。

2.5 联合业务做好压测

由于有压力和无压力下，暴露出来的问题是不一样的，最好是能联合业务，在生产环境做一次压测，把MySQL的性能隐患充分暴露出来、然后有针对性治理

2.6 做好MySQL监控

主要是做好性能指标和容量指标的观测并及时告警，可参考以下指标：

CPU利用率 、连接数利用率 、运行的线程数 、主从延迟时间 、慢查询数 、Innodb缓存命中率 、磁盘利用率 等

2.7 混沌工程

从架构维度来看，MySQL属于数据层，且是数据层的持久化组件，起到最终的兜底作用，所以MySQL的集群波动、性能异常等，往往会对业务带来意想不到的冲击，不要认为前面有缓存就万事大吉，缓存对象的集中过期、用户流量波动叠加MySQL的异常，后果完全会超越想象。所以有时间的话，最好带着压力，来针对数据库做混沌，观察业务表现。不熟悉混沌的同学可以参考我另一篇文章：【万字长文】腾讯云新能源汽车客户-混沌工程实战-腾讯云开发者社区-腾讯云

建议的混沌项目：

3、事中应急手段

3.1 紧急扩容

结合MySQL监控，一旦发生容量不足的情况，可以考虑上面2.2介绍的方法，进行容量扩充。如果仍不能缓解，可以联系您的售后顾问请求支持

3.2 kill慢sql

另外一种常见的方法，就是kill慢SQL、如果慢SQL是频繁复发，可以考虑持续kill

操作步骤：

1. 登录 登录 - 腾讯云。

2. 在左侧导航栏，选择诊断优化。

3. 在页面上方选择数据库类型和实例 ID，选择实时会话页签。

4. 在实时会话页面，选择活跃会话页签。

5. 在列表上方选择实时会话。

6. 在实时会话列表中勾选待 KILL 的会话，在列表右上方单击 Kill 会话，在弹出的对话框中单击确定。

KILL 会话后，可在列表上方单击历史记录，查看已 KILL 会话。

数据库智能管家 DBbrain KILL 会话-操作指南-文档中心-腾讯云

3.3 索引优化

根据请求的SQL情况，如果慢SQL是我们之前未预料到的，可以通过临时索引优化来缓解

3.4 限流

也可以考虑通过限流，来避免业务整体中断；通过部分请求失败+前端界面友好提示，降低业务中断、用户投诉的风险

数据库智能管家 DBbrain 创建 SQL 限流任务-操作指南-文档中心-腾讯云

3.5 业务优化

经过上面手段后，数据库仍然有问题，最后在考虑业务开发优化程序，不过一般此时起的作用就比较小且耗时很久。互联网公司很多上热搜的故障，都是走到了业务优化，但业务优化又需要较长的时间。