开发者学堂课程【如何在 PolarDB-X 中优化慢 SQL：如何在 PolarDB-X 中优化慢 SQL】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/987/detail/14930
如何在 PolarDB-X 中优化慢 SQL
内容介绍：
一、动手实践系列介绍
二、环境准备
三、演示内容
一、动手实践系列介绍
首先是围绕 PolarDB-X 的社区版也就是开源的版本来讲解，它对标的是阿里云上商业2.0版本，它所面向的群体是应用开发者、架构师、 DBA 等等，站在用户的视角来展示 PolarDB-X 产品应该如何使用，讲解的主要内容是围绕 PolarDB-X 在使用的全过程当中以场景化的方式来进行展示。
之后会讲如何连接 PolarDB-X 之后，会讲 DDL 、扩缩容以及全局 Binlog 增长日志。今天讲解如何优化的 PolarDB-X 里面的 MySQL 。题目后续也会有所调整。
二、环境准备
1、系统
CentOS 7、8
macOS
Ubuntu 18、20、21、22
Windows 10+
2、配置
>= 4C8G
3、环境
Docker&K8S
PolarDB-X Release-20220127
环境配置也需要有系统，最好是 CentOS 或者是 Ubuntu ，配置要稍微高一点，环境需要里面有一个 Docker&K8S 集群，以及PolarDB-X Release-20220127 。
首先了解一下 PolarDB-X 的系统架构， PolarDB-X 分布式系统有四大组件。第一个组件叫做 CN 也是分布式计算，主要负责数据拆分的计算以及分布式事务等等功能。第二个是 DN 为了方便理解可以把它简单的理解成是增强版的 MySQL ，负责数据的存储。第三个组件 GMS 是原数据中心，是一个高频率的节点，可以看成一个特殊角色的 DN 。最后一个全体 Blog 生成的组件叫 CDC，它可以生成 MySQL 增量日志。这是 PolarDB-X 的架构。
| NO. | RULE_NAME | RUNNING | WAITING | KILLED | MATCH_HIT_CACHE | TOTAL_MATCH | ACTIVE_NODE_COUNT | MAX_CONCURRENCY_PER_NODE | WAIT_Q UEUE_SIZE_PER_NODE | WAIT_TIMEOUT | FAST_MATCH | LIGHT_WAIT | SQL_TYPE | USER TABLE | KEYWORDS | TEMPLATE _ID |
三、演示内容
1、PolarDB-X SQL Advisor&CCL Demo：
模拟业务A : Sysbencholtp
模拟业务B : randomselect
SOL 限流慢 SOL
SOL Advisor 优化慢 SQL
2、SQL Advisor 原理 ：
基本原理和流程
了解更多
小图是用来模拟的一个线上的业务场景，首先用阿里云上的 ECS 来做所有的环境的部署，假设业务系统里面用 PolarDB-X 作为数据库，同时用 Prometheus 和 Grafana 作为监控的电路，在业务上面一开始会运行的一个老的应用叫 APP A 它是在正常运行的，过了一段时间业务发展又有一个新的业务加入称它为 APP B ，它是跟 APP A 是共享一个 PolarDB-X 库的，今天模拟的场景是这 APP B 刚加入的时候因为它的数据库表的一些设计不够合理，导致 APP B 启动的时候把线上的 PolarDB-X 实例资源占用非常的多，影响到了APP B 的使用，在这样情况下，怎么样做应急的处理，会用到一系列 PolarDB-X 提供的工具。主要会介绍两个，第一个叫 SQL Advisor 推荐的能力。第二个是 CCL 也是 SQL 限流的工具，用 Sysbench oltp 压测的场景来模拟业务 A ，跑的实际上是 Sysbench 的 oltp 场景。 APP B 是用 Sysbench 里面 random select 的场景，APP A 用 oltp 是听取上一讲当一个同学的建议，上次讲 SQL 都是select 没有对下层数据的修改，所以做第二个可能相当是比较容易的。这次就具体建议用 oltp 里面既有读也有写的业务的负担。
3、Demo 环节
free6om@free6om ~> ssh polardb-x-demo
Welcome to Ubuntu 20.04.3 LTS(GNU/Linux 5.4.0-91-generic
*Documentation: https://help.ubuntu.com
*Management: https:///landscape.canonical.com
*Support: https://ubuntu.com/advantage
Welcome to Alibaba Cloud Elastic Compute Service !
Last loain: Fri Mar 11 14:08:01 2022 from 42120.73.190 Welcome to fish，the friendly interactive shell
Type 'help ’ for instructions on how to use fish
admin@polardb-x-demo ~> cd class-6/
admin@polardb-x-demo ~/class-6> kc port-forward sql-advis or-and-cc1-tvkd-cn-default-c7b498f84-j5wd7 8081:8081 --ad dress="0.0.0.0"
Forwarding from 0.0.0.0:8081 -> 8081
Handing connection for 8081
//把监控链路打通
//页面是用 General 来展示 PolarDB-X 的一个系统监控，过大概30秒监控数据就会过来。
X1
Last login: Fri Mar 11 13:49:04 on ttys003
You have mail.
Welcome to fish, the friendly interactive shell
Type 'help ’ for instructions on how to use fish
Free6om@free6om ~> ssh polardb-x-demo
Welcome to Ubuntu 20.04.3 LTS(GNU/Linux5.4.0-91-generic x86_64)
*Documentation: https://help.ubuntu.com
*Management: https://landscape.canonical.com
*Support: https://ubuntu.com/advantage
Welcome to Alibaba Cloud Elastic Compute Service !
Last login: Fri Mar 11 14:08:01 2022 from 42.120.73.190 Welcome to fish, the friendly interactive shell
Type 'help ’ for instructions on how to use fish
admin@polardb-x-demo ~> cd class-6/
admin@polardb-x-demo ~/class-6> mysql -h127.1 -upolar dbx_root -p6pmzs57p
mysql:[Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ;or\g. Your MySOL connection id is 17935
Server version: 5.6.29 Tddl Server(ALIBABA)
Copyright (c)2000,2021, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
Type 'help;’or '\h’ for help. Type '\c’ to clear the current input statement.
//先启动一个 shell 登录到 ECS 连上 PolarDB-X 数据库。
//监控数据已经过来，当前系统没有什么负载，QPS 比较低是一个空跑的状态。
//看一下目前 PolarDB-X 里面都有什么库。
mysql> show databases;
+----------------------+
| DATABASE |
+----------------------+
| app_a |
| app_b |
| app_b_idx |
| information_schema |
+-----------------------+
//有 app_a 、app_b、app_b_idx 的库，先不用管 app_b和app_b_idx 只看 app_a ，接下来的操作是把模拟场景里面的APP A 也就是老的应用，先正常的起来。
4 rows in set (0.00 sec)
mysql> use app_a;
Database changed
mysql> show tables;
Empty set (0.00 sec)
mysql>
// app_a 库里面是没有表的，所以接下来先把表换成数据。再打开第三个 shell
Last login: Fri Mar 11 16:09:06 on ttys001
You have mail.
Welcome to fish, the friendly interactive shell
Type `help’for instructions on how to use fish
free6om@free6om~> ssh polardb-x-demo
Welcome to Ubuntu 20.04.3 LTS (GNU/Linux5.4.0-91-generic x86_64)
*Documentation: https://help.ubuntu.com
*Management: https:///landscape.canonical.com
*Support: https://ubuntu.com/advantage
Welcome to Alibaba Cloud Elastic Compute Service!
Last login: Fri Mar 11 16:09:09 2022 from 42120.73.190 Welcome to fish the friendly interactive shell
Type `help’for instructions on how to use fish admin@polardb-x-demo ~> cd class-6/
admin@polardb-x-demo ~/class-6> kc apply-f sysbench-prep are-app_a.yaml
//这个脚本依然是前两次往里面加载 sysbench 数据的脚本。把它跑起来可以看到现在已经有 s 的 job 在跑了。
job.batch/sysbench-prepare-app-a-data-test created
admin@polardb-x-demo ~/class-6> kc get jobs
NAME COMPLETIONS DURATION AGE
sysbench-prepare-app-a-dataetest 0/1 4s 4s
admin@polardb-x-demo ~/class -6>kc get pods
NAME READY STATUS Running RESTARTS AGE
sql-advisor-and-ccl-tvkd-cdc-default-7c69659b47-rjkg9 2/2 Running 0 27h
sql-advisor-and-ccl-tvkd-cn-default-c7b498f84-j5wd7 3/3 Running 0 24h
sql-advisor-and-ccl-tvkd-dn-0-single-0 3/3 Running 27h
sql-advisor-and-ccl-tvkd-dn-1-single-0 3/3 Running 27h
sql-advisor-and-ccl-tvkd-gms-single-0 3/3 Running 27h
sysbench-prepare-app-a-Wata-test--1-9mtzt 1/1 Running 13s
admin@polardb-x-demo ~/class-6>kc logs-f sysbench-prepa re-app-a-data-test--1-9mtzt
//处于 Running 的状态，看一下日志。
transactions: 1 (0.11 per sec.)
queries: 64 (7.05 per sec.)
ignored errors: 0 (0.00 per sec.)
reconnects: 0 (0.00 per sec.)
General statistics:
total time: 9.0763s
total number of events: 1
Latency(ms):
min: 9075.87
avg: 9075.87
max: 9075.87
95th percentile: 9118.47
sum: 9075.87
Threads fairness:
events(avg/stddev): 1.0000/0.00
execution time(avg/stddev): 9.0759/0.00
admin@polardb-x-demo ~/class-6> kc apply - sysbench-o ltp.yaml
job.batch/sysbench-oltp-test created
admin@polardb-x-demo ~/class-6>
//已经跑完了，再看app_a 的情况，已经有了一张表 sbtest1
mysql> show tables;
+--------------------+
| TABLES_IN_APP_A |
+--------------------+
| sbtest1 |
+--------------------+
row in set(0.01 sec)
mysql> select count(*) from sbtest1;
+-----------+
| count(*) |
+-----------+
| 160000 |
+-----------+
1 row in set (0.03 sec)
//里面有16万数据，跟上次演示 DDL 是一样的，现在有一张表它里面有10万条数据，接下来启动 sysbench 的 oltp 场景，把业务流量起来。
//通过 show processlist 看业务 A 的链接有没有正常过来
mysql> show processlist；
+---+-------+---------+---+--------------+-------+--------+------
| ID | USER | HOST |DB | COMMAND | TIME | STATE | INFO |TRACEID|
| 17972| polardbx_root|172.17.0.1:34086 |app_a |Query| 0 | |INSERT INTO sdtest1（id，k,c, 13f872fea8402003|
|17976 |polardbx_root |172.17.0.1:49259 |app_a |SLEEP | 0| | NULL | 13f872fea8002002|
| 15705 | polardbx_root | 172.17.0.1:61081| __cdc__ | SLEEP| 0 | | NULL| 13f872f62e402002|
| 17969 | polardbx_root| 172.17.0.1:63296| app_a | SLEEP| 0 | | NULL| 13f872fea8802003|
| 17973| polardbx_root| 172.17.0.1:7172| app_a |Query| 0 | | INSERT | INTO| sbtest 1 (id,k,c | 13f872fea8002000|
|9 | polardbx_root |172.17. 01:45597 | NULL| | 13f872fe7c802002|
|17935 | polardbx_root| 127.0.0 1:40582| app_a | Query |0| | show processlist | 13f872fea8802001|
| 16480 | polardbx_root | 127.0.0 1:34562 | app_b |SLEEP| 7300 | | NULL |13f85725b3002000|
| 17970 | polardbx_root |172.17. 01:63100| app_a |Query |0 | | UPDATE sbtest1 SEST k=k+1 WHERE| 13f872fea8c02000
| 17974 | polardbx_root |172.17. 0.1:21582 | app_a| QUERY| 0 | | 13f872fea8402004|
| 17971 | polardbx_root | 172.17. 0.1:52470 | app_a | QUERY| 0 | | UPDATE sbtest1 SET k=k+1 WHERE | 13f872fea8802000|
| 17975 | polardbx_root | 172.17.0.1:60296| app_a| Query |0 | | SELECT c FORM sbtest1 WHERE id | 13f872fea8c02001|
+---+-------+---------+---+--------------+-------+--------+------
12 rows in set (0.00 sec)
//里面会有一些 INSERT、UPDATE、SELECT 语句
//看一下系统监控，可以看到 QPS 有一个快速的提升，从原来的15提升到现在的4600的水平，等系统负载跑稳定围绕在4500的水平，业务 A 已经正常运行很长时间，库也是正常的，之后 APP B 要上线
//先看一下 APP B 库里面有什么
mysql> use app_b;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+---------------------+
| TABLES_IN_APP_B |
+---------------------+
| sbtest1 |
+---------------------+
1 row in set (0.00 sec)
mysql>select count(id) from sbtest1;
+-------------+
| count(id) |
+-------------+
| 32000000 |
+-------------+
1 row in set (0.44 sec)
mysql>show creat table sbtest1；
//可以看到里面有一张名叫 sbtest1 的表，为了演示效果，在 sbtest1 里面灌了比较多的数据，一共3200万条数据，如果直接演示数据周期会比较长，大概十几分钟，为了 Demo 节省时间，所以提前把数据给加载进去了，所以跳过 EOB 上线之前加载数据的过程，假设里面一开始就有这么多数据。我们再来看一下现在他们。
//现在数据的表结构
-------------------------------------------------------------------
------------------------------+
| Table | Create Table
|
+--------------+---------------------------------------------------------------------------------------------------------------------
------------------------------+
| sbtest1 | CREATE TABLE`sbtest1`(
`id` int(10) UNSIGNED NOT NULL，
`k` int(10) UNSIGNED NOT NULL DEFAULT '0',
`c`char(120) NOT NULL DEFAULT'',
`pad` char(60) NOT NULL DEFAULT''
KEY `xid` (`id`)
)ENGINE=InnODB AUTO_INCREMENT=32454182 DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE =utf8mb4_0900_ai_ci dbpartition by hash(`id`) l
+--------------+---------------------------------------------------------------------------------------------------------------------
------------------------------+
1 row in set (0.01 sec)
mysqi>
//里面有 id、k、c 和 pad 其中 KEY 是索引，同时呢 sbtest1是一个分工表，用 id 做 hash 进行分表，这是目前表的状态。这个时候业务 B 的数据库建好了，现在把业务 B 的应用给起来。
//业务 B 用了 sysbench-selec-k 场景，官方叫 Select Random 场景团体，简单来说是 yaml 条件里面以 K 这样的一个引力做yaml 条件。做一个查询先把它起来，起来之后来模拟业务 B 的上限。此时观察一下监控的 QPS 情况。
admin@polardb-x-demo ~/class-6> kc apply -f sysbench-olt p.yaml
job.batch/sysbench-oltp-test created
admin@polardb-x-demo ~/class-6> ls
sql-advisor-and-ccl.yaml sysbench-prepare-app_a.yaml sysbench-select-k-idx.yam1
sysbench-oltp.yaml sysbench-prepare-app_b.yaml sysbench-select-k.yaml
admin@polardb-x-demo ~/class-6>
//QPS 从原来4500左右非常陡峭的降低，降低到2300，再次已经降到200多，此时作为一个运维，应该收到系统的报警，作为应用 A 的比如 oner 收到报警，通知 DBA ，DBA 就上线。
mysql>show slow;
//PolarDBX提供指令 show slow 这样的一个显示，慢查询的一个思考语句。
| 13f873e48d002001 | polardbx_root | 172.17.0.1 | 2022-03-11 08:16:05 | 11504 | SELECT id, k. c. pad FROM sbtest1 WHERE K IN (?)|
| 13f873e4c4002001 | polardbx_root | 172.17.0.1 | 2022-03-11 08:16:05 | 11392| 0 | SELECT id, k, c, pad FROM sbtest1 WH ERE k IN (?)|
| 13f873d9ac802000 | polardbx_root | 172.17.0.1 | 2022-03-11 08:15:54 11358 | 0 | SELECT id, k, c, pad FROM sbtest1 WHERE K IN (?)|
| 13f873d9a3c02000 | polardbx_root | 172.17.0.1 | 2022-03-11 08:15:54 | 11271 | 0 | SELECT id, k, c, pad FROM sbtest1 WHERE K IN (?) |
| 13f873d964002000 | polardbx_root |172.17.0.1 | 2022-03-11 08:15:54 | 11249 | 0 I SELECT id, k, c, pad FROM sbtest1 WH ERE K IN (?)|
| 13f873e5d3002002 | polardbx_root | 172.17.0.1 | 2022-03-11 08:16:06 | 11100 | 1 | SELECT id, k, c, pad FROM sbtest1 WH ERE K IN (?){|
| 13f873da33002000 | polardbx_root | 172.17.0.1 | 2022-03-11 08:15:54 | 10596 | 0 | SELECT id, k, c, pad FROM sbtest1 WH ERE K IN (?)|
| 13f873cdfc002000 | polardbx_root|172.17.0.1 |2022-03-11 08:15:34 | 34901 |1 | SELECT SUMCK) FROM sbtest1 WHERE id
BETWEEN 80513 AND 80517
| 13f873c114c02000 | polardbx_root | 172.17.0.1 | 2022-03-11 08:15:21| 34851 |5 | SELECT c FROM sbtest1 WHERE id BETWE
EN 96023 AND 96027
| 13f873c119802000 | polardbx_root | 172.17.0.1| 2022-03-11 08:15:21 | 3477| 5 |SELECT c FROM sbtest1 WHERE id BETWE
EN 79858 AND 79862
| 13f873cdfdc02000 | polardbx_root | 172.17.0.1| 2022-03-11 08:15:34 | 3476| 5 | SELECT c FROM sbtest1 WHERE id BETWE
| 13f873ce10002000 | polardbx_root | 172.17.0.1|2022-03-11 08:15:34 | 3405 | 5 | SELECT DISTINCT c FROM sbtest1 WHERE
id BETWEEN 80470 AND 80474 ORDER BY c |
| 13f873ce0e402000-4| polardbx_root17217.0.1| 2022-03-11 08：15：34 | 3397| 2 I replace into `__cdc__.`__cdc_hear tb eat(id,sn ame,gmt_modified) values (1."heartbea，'2022-03-11 08:15:30.831')|
| 13f873c0ff002000 | polardbx_root | 172.17.0.1 |2022-03-11 08:15:20 | 2720 | 1 | SELECT c FROM sbtest1 WHERE id=80752|
| 13f873cdfa002000 | \polardbx_root 1172.17.0.1 |2022-03-11 08:15:33 | 2704 |5| SELECT DISTINCT c FROM sbtest1 WHERE id BETWEEN 64715 AND 64719 ORDER BY C|
| 13f873c104002000 | polardbx_root | 172.17.0.1 |2022-03-11 08:15:20 | 2704| 1 | SELECT c FROM sbtest1 WHERE id=80620 |
| 13f873c105402000 | polardbx_root |172.17.0.1 |2022-03-11 08:15:20 | 2691 | 5 | SELECT c FROM sbtest1 WHERE id BETWEEN 80245 AND 80249|
| 13f873cdfe002000 | polardbx_root | 7217.0.1 |2022-03-11 08:15:33 |2669| 1 |SELECT SUM(K) FROM sbtest1 WHERE id BETWEEN 92237 AND 92241|
| 13f873ce05002001 | polardbx_root | 172.17.0.1 |2022-03-11 08:15:33 |2660| 5 | SELECT c FROM sbtest1 WHERE id BETWEEN 80602 AND 80606|
| 13f873c116c02000 | polardbx_root | 172.17.0.1 |2022-03-11 08:15:20 | 2621| 1 | SELECT c FROM sbtest1 WHERE id=57892|
| 13f873c11b002000 | polardbx_root | 172.17.0.1 | 2022-03-11 08：15：20 |2609| 1| SELECT c FROM sbtest1 WHERE id=79894 |
| 13f873c292002000 | polardbx_root |172.17.0.1 | 2022-03-11 08:15:21 1972| 1 | UPDATE sbtest1 SET c-'78407556466-02 075916779-65739334302-94780306271-46900350015-80231210947-26308605742-20247457467-66192878294-03605546608’WHERE id-699561|
| 13f873cfa5002000 | polardbx_root | 172.17.0.1 2022-03-11 08：15:34 | 1794| 1 | UPDATE sbtest1 SET k=k+1 WHERE id=80383|
| 13f873cdfc802000 | polardbx_root | 172.17.0.1 | 2022-03-11 08:15:32 | 1689 | 5 | SELECT DISTINCT c FROM sbtest1 WHERE id BETWEEN 79643 AND 79647 ORDER BY c |
| 13f873ce03002000 | polardbx_root | 172.17.0.1 2022-03-11 08:15:32 | 1664 | 5 | SELECT DISTINCT c FROM sbtest1 WHERE id BETWEEN 80455 AND 80459 ORDER BY C|
| 13f873c11a002000 |polardbx_root |172.17.0.1| 2022-03-11 08:15：19 |1497| 1 |UPDATE sbtest1 SET k=k+1 WHERE id=80773|
| 13f856d4efc02000 | polardbx_root | 127.0.0.1 | 2022-03-11 06:08:57 | 1462| 5 |explain analyze select id,k.c.pad from sbtest1 where k in(3)|
| 13f856cd5c402000 |polardbx_root |127.0.0.1 |2022-03-11 06:08:49| 1456| 5|explain analyze select id.k.c.pad from sbtest1 where k in (3)|
| 13f873e818002000 |polardbx_root | 172.17.0.1 | 2022-03-11 08:15:59 |1155| 1 | SELECT c FROM sbtest1 WHERE id=80399|
| 13f873e820c02001 | polardbx_root| 1172.17.0.1| 2022-03-11 08:15:59 | 1124 | 5 | SELECT c FROM sbtest1 WHERE id BETWEEN 80613 AND 80617 ORDER BY C|
| 13f873e820c02000 | polardbx_root | 172.17.0.1 | 2022-03-11 08:15:59| 1120 | 1 | UPDATE sbtest1 SET k=k+1 WHERE id=80045|
| 13f873e820402000 | polardbx_root |172.17.0.1 |2022-03-11 08:15:59 | 1118 |5 | SELECT DISTINCT c FROM sbtest1 WHERE id BETWEEN 80213 AND 80217 ORDER BY C|
| 13f873e820402001 | polardbx_root | 172.17.0.1 | 2022-03-11 08:15:59 | 1110| 1 | SELECT c FROM sbtest1 WHERE id=80801
+----------+----------+--------+--------+--------+-------+-------------------------------------------------------+
55 rows in set (0.01 sec)
//原来业务 A 里面所有的 sql 都是正常跑的，所以优先略过 A 里面的 sql ，重点怀疑新来的业务 B 发起的 sql ，“SELECT id, k, c, pad FROM sbtest1 WH ERE K IN (?)”由业务 B 发出sql
//因为我们的业务系统非常富复杂，第一步先把 myscl 禁止掉让业务 A 恢复正常，然后定位问题，之后再看解决方法。所有为了应急先把导致系统 DBX 下降的 mysql 禁止掉，可以用到 PolarDB-X 提供的 sql 限流功能
//b 上所有的表都做一个限制对象，关键字过滤的功能，过滤” pad“ ” max_concurrency =0“意思为遇到这样的 sql 全部堵塞
mysql>creat ccl_rule block_bad_sql on app_b，*to`polardbx_root`@`%`for select filter by keyword（”pad“）with max_concurrency=0；
Query OK, 1 row affected (0.08 sec)
mysql> show ccl_rules;
+---+---------+---+---+-----+-------+---------+---------+---------------------+--------+-----------+-----------+----------+----------------+
| NO. | RULE_NAME | RUNNING | WAITING | KILLED | MATCH_HIT_CACHE | TOTAL_MATCH | ACTIVE_NODE_COUNT | MAX_CONCURRENCY_PER_NODE | WAIT_Q UEUE_SIZE_PER_NODE | WAIT_TIMEOUT | FAST_MATCH | LIGHT_WAIT | SQL_TYPE | USER TABLE | KEYWORDS | TEMPLATE _ID | QUERY | CREATED_TIME|
+---+---------+---+---+-----+-------+---------+---------+---------------------+--------+-----------+-----------+----------+----------------+
| 1 | block_bad_sql | 0 | 0 | 20478 | 20477 | 20478 | 1 | 0 |
0| 600| 1| 1|SELECT | polardbx_root@% | app_b.* | ["pad"] | NULL |NULL | 2022 -03-11 16:18:42|
+---+---------+---+---+-----+-------+---------+---------+---------------------+--------+-----------+-----------+----------+----------------+
1 row in set (0.03 sec)
mysql>
//可以看到已经开始做拦截，重点关注 RUNNING、WAITING、 KILLED 几个参数，现在已经 killed 20478 个参数，block_bad_sql 限流的规则已经开始生效了，生效完之后业务 A 已经恢复正常。看一下监控数据，最早的只有业务 A 在运行的时候4500 QPS 水位因为业务 B 的加入导致降到两三百，限流规则生效之后整个 QPS 系统恢复到了6800，比以前高的原因是被 sql 限流功能限掉的 sql 也算在了统一之内，业务 A 已经恢复正常。
