自动SQL限流

DAS支持自动SQL限流功能，您可以设置触发条件，当相关条件满足时会自动触发SQL限流。

前提条件

目标数据库实例为：
- RDS MySQL 5.6、5.7、 8.0高可用版、三节点企业版。
- PolarDB MySQL 5.6集群版、5.7集群版、 8.0集群版、8.0历史库。
目标数据库实例已开启自治服务，详情请参见自治中心。
目标数据库实例已开启SQL洞察，详情请参见SQL洞察。

说明当慢SQL优化完成后，可能会出现全局性能变差的问题，为了提升SQL自动优化的准确率，建议开启SQL洞察。

适用场景

自动限流主要应用在以下3种场景：

流量问题：出现缓存穿透或异常调用情况，导致某类SQL并发量急剧上升。
数据问题：存在大订单数据的账号，该账号的相关SQL占用大量数据库资源。
SQL问题：未创建索引的SQL被大量调用，影响正常业务。

操作步骤

登录DAS控制台。
在左侧导航栏中，单击实例监控。
找到目标实例，单击实例ID，进入目标实例详情页面。
在例详情页面左侧导航栏中，单击自治中心。
在自治中心页面，单击右侧自治功能开关。

在弹出的设置对话框中，开启自动限流，并设置如下参数作为自动限流的触发条件。


参数	描述
CPU利用率	大于等于70%。
活跃会话数	大于等于16且为整数。
持续时间	大于等于2分钟，最大限流时间不能为负数。

说明例如在可限流时间段内，自定义触发条件为当CPU使用率大于80%，同时活跃会话数大于64，且该现象持续时间超过2分钟时触发自动限流，同时自动开始跟踪：

如果发现故障未消除，则自动回滚该限流操作。
自动限流触发后，限流操作持续的时间不会超过最大限流时间。
若选中同时KILL执行中的异常SQL，则即将被限流的异常SQL也会被KILL，以便快速提升实例性能。若目标数据库实例为PolarDB MySQL 5.7或PolarDB MySQL 8.0且主库是否接受读设置为否时，在限流后自动KILL的情况下可能存在部分读流量转发到主节点的现象，详情请见负载均衡、配置数据库代理。

单击确定。
说明当自动限流规则创建后，应用端使用了同时包含所有关键词的SQL语句：
- RDS MySQL 5.6、RDS MySQL 5.7的实例和PolarDB MySQL 5.6的集群会返回1317错误（query execution was interrupted）。
- RDS MySQL 8.0实例、PolarDB MySQL 5.7和PolarDB MySQL 8.0集群会让相关SQL会处于Concurrency control waiting状态，直至等待数量超过ccl_max_waiting_count参数的值（如果实例版本支持该参数）时，会返回错误码和错误描述（Concurrency control waiting count exceed max waiting count），错误码分别是：
  
  RDS MySQL 8.0为ERROR 7534 (HY000)。
  
  PolarDB MySQL 5.7为ERROR 3277 (HY000)。
  
  PolarDB MySQL 8.0为ERROR 7533 (HY000)。
  
  其中，若ccl_max_waiting_count参数值为默认值0时，所有被限流的SQL均会处于Concurrency control waiting状态，不返回错误。通过DAS限流时，若该参数值为0，DAS会将其值设置为DAS的默认值；若用户将其设置为大于0的其他值，DAS不再设置该参数，直接使用用户的设置。

应用场景

异常检测
该模块通过机器学习对实例历史性能数据进行离线训练获得相关模型，并利用该模型对实时指标数据进行异常检测。相比于阈值告警，7x24小时的异常检测能更及时的发现异常。
根因分析
该模块会订阅实例的异常事件并采集出现异常时的会话信息，结合SQL审计中的全量SQL和performance_schema中的统计信息进行判断，定位实例异常的原因，原因通常分为如下几种：
- 阻塞型SQL
  DAS能够通过分析实时会话、锁等待和运行中的事务，判断是否存在DDL变更、锁等待和大事务等情况。同时DAS还能分析和判断被影响会话的数量和执行时间，如果被影响的会话比较多或执行时间很长，则该异常无需通过限流SQL来解决，而是Kill异常会话。
- 资源消耗型SQL（即烂SQL）
  该场景中，可能SQL的并发量不大，但会消耗大量的CPU、IO或网络资源，并且会持续不断地被提交。
- 流量型SQL
  大量的正常SQL在数据库中同时运行，触发数据库的资源瓶颈，甚至导致KV类查询SQL的响应时间都出现了异常。
- 其他
  未涵盖在上述3种场景中的任何情况。
自动限流
当发现实例存在上述根因分析中的第2和第3种场景（即资源消耗型SQL和流量型SQL）时，DAS会自动提取SQL特征，并对异常SQL进行限流（需先获得您的授权后才会触发）。
特征选取
如果发现存在需要限流的异常SQL，下一步就需要确定SQL的特征进行精确限流，防止因特征选取错误导致业务全面受损。理想情况下特征是唯一的，只对识别到的异常SQL进行限流而不影响其它SQL。首先要区分SQL模版限流和SQL文本限流。
- SQL模板限流
  SQL模板是指将SQL文本的具体参数抽象化后的文本。这类SQL并发度高都会产生问题，但与具体参数无关，因此特征只需要包含模板特征即可。这类限流主要应对突增流量、无索引等场景。
- SQL文本限流
  同一类模板中一些SQL执行正常，另一些SQL执行异常，此时特征中既要包含SQL模板信息，又要包含具体参数信息。这类限流主要应对数据倾斜的场景。
对于SQL模板限流，如果SQL中包含模板ID信息，会优先使用ID类信息（如使用数据库中间件根据模板自动生成的SQL模板ID或者开发人员在SQL模板中添加的HINT信息）。使用ID的优点是容易保证模板唯一，不会对其它模板的SQL造成影响；缺点是SQL如果不带ID信息（比如通过命令行手动执行）则不受限流并发度控制，仍然可以执行。

如果SQL中不包含模板ID信息，那就需要提取文本信息。SQL模板在分析过程中已经计算获得。如下所示的SQL1和SQL2计算后分别可以得到模板1和模板2。对模板1进行限流，可以获得的最全特征为select id, name, age from students where name。使用该特征进行限流，优点是不管通过哪种连接方式发送的SQL，只要满足该特征都受限流并发度控制；缺点是存在误限流的可能性，比如模板2包含模板1中的所有特征。
```
/* SQL文本1 */
select id,name,age from students where name='张三';
/* SQL模板1 */
select id,name,age from students where name = ?;
/* SQL文本2 */
select id,name,age from students where name='张三' and sid='唯一ID';
/* SQL模板2 */
select id,name,age from students where name=? and sid=?
```
自动优化
当根因分析模块发现存在可优化的异常SQL时，除了发起限流应急处理外，还会将异常SQL发送到自动优化模块，自动创建索引进行优化。
跟踪和回滚
自动限流后，DAS会持续跟踪，如果发现限流后，数据库的负载并未降低或降低的流量同预估出现偏差，则会自动回滚限流操作，并再次启动根因分析。

了解更多

关于自动SQL限流的详细技术解读，详情请参见自动SQL限流。

前提条件

适用场景

操作步骤

应用场景

相关API

了解更多