13518219792
题主是否想询问“mysql无法关闭怎么办”?
成都创新互联公司是一家集网站建设,临渭区企业网站建设,临渭区品牌网站建设,网站定制,临渭区网站建设报价,网络营销,网络优化,临渭区网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。
1、首先查看活动监视器中的用户。
2、接着打开命令窗口。
3、最后执行“sudo /usr/local/mysql/support-files/mysql.server stop”命令即可。
你这个问题其实就是问mycat的相关用法吧：
1、安装
现在网上很多教程是直接从show @@help;开始的，这个前提是你已经装好了mycat，否则你直接执行这个命令显然只能看到错误信息。
不过你既然已经提问到mycat了，应该已经装好了，我这里就不搬运安装的教程了，如果没装好，自行搜索教程并安装。
2、使用
1）登录
mysql -utest -ptest -P9066
9066是登录mycat的端口
2）help
show @@help;
执行这个如果运行成功（也可能运行不成功的，如果你没装mycat的话），则说明mycat正常，可以进行监控。
3）监控命令（以下是搬运）
A）show @@backend
显示后端物理库连接信息，包括当前连接数，端口
B）show @@connection
显示当前前端客户端连接情况，已经网络流量信息
C）show @@threadpool
当前线程池的执行情况，是否有积压(active_count)以及task_queue_size，后者为积压的待处理的SQL，若积压数目一直保值，则说明后端物理连接可能不够或者SQL执行比较缓慢。
D）show @@heartbeat
当前后端物理库的心跳检测情况,RS_CODE为1表示心跳正常
E）show @@datanode
显示数据节点的访问情况，包括每个数据节点当前活动连接数(active),空闲连接数（idle）以及最大连接数(maxCon) size，EXECUTE参数表示从该节点获取连接的次数，次数越多，说明访问该节点越多。
F）show @@processor
显示当前processors的处理情况，包括每个processor的IO吞吐量(NET_IN/NET_OUT)、IO队列的积压情况(R_QUEY/W_QUEUE)，Socket Buffer Pool的使用情况BU_PERCENT为已使用的百分比、BU_WARNS为Socket Buffer Pool不够时，临时创新的新的BUFFER的次数，若百分比经常超过90%并且BU_WARNS0，则表明BUFFER不够，需要增大，参见性能调优手册。
G）show @@datasource
显示数据源的信息，是否是读写节点等。
H）show @@cache
显示缓存的使用情况，对于性能监控和调优很有价值
MAX为缓存的最大值（记录个数），CUR为当前已经在缓存中的数量，ACESS为缓存读次数，HIT为缓存命中次数，PUT 为写缓存次数，LAST_XX为最后操作时间戳，比较重要的几个参数：CUR：若CUR接近MAX，而PUT大于MAX很多，则表明MAX需要增大，HIT/ACCESS为缓存命中率，这个值越高越好。
I）kill @@connection
杀掉客户端的连接，参数为连接的ID值，通过show @@connection，可以展示当前连接到MyCAT的所有客户端进程，若某个进程异常，则可以通过该命令杀掉连接，如
kill @@connection 1;
首先介绍下 pt-stalk，它是 Percona-Toolkit 工具包中的一个工具，说起 PT 工具包大家都不陌生，平时常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于这个工具包，这里就不多介绍了。
pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息，这其中包括：
1. OS 层面的 CPU、IO、内存、磁盘、网络等信息；
2. MySQL 层面的行锁等待、会话连接、主从复制，状态参数等信息。
而且 pt-stalk 是一个 Shell脚本，对于我这种看不懂 perl 的人来说比较友好，脚本里面的监控逻辑与监控命令也可以拿来参考，用于构建自己的监控体系。
三、使用
接着我们来看下如何使用这个工具。
pt-stalk 通常以后台服务形式监控 MySQL 并等待触发条件，当触发条件时收集相关诊断数据。
触发条件相关的参数有以下几个：
function：
∘ 默认为 status，代表监控 SHOW GLOBAL STATUS 的输出；
∘ 也可以设置为 processlist，代表监控 show processlist 的输出；
variable：
∘ 默认为 Threads_running，代表 监控参数，根据上述监控输出指定具体的监控项；
threshold：
∘ 默认为 25，代表 监控阈值，监控参数超过阈值，则满足触发条件；
∘ 监控参数的值非数字时，需要配合 match 参数一起使用，如 processlist 的 state 列；
cycles：
∘ 默认为 5，表示连续观察到五次满足触发条件时，才触发收集；
连接参数：host、password、port、socket。
其他一些重要参数：
iterations：该参数指定 pt-stalk 在触发收集几次后退出，默认会一直运行。
run-time：触发收集后，该参数指定收集多长时间的数据，默认 30 秒。
sleep：该参数指定在触发收集后，sleep 多久后继续监控，默认 300 秒。
interval：指定状态参数的检查频率，判断是否需要触发收集，默认 1 秒。
dest：监控数据存放路径，默认为 /var/lib/pt-stalk。
retention-time ：监控数据保留时长，默认 30 天。
daemonize：以后台服务运行，默认不开启。
log：后台运行日志，默认为 /var/log/pt-stalk.log。
collect：触发发生时收集诊断数据，默认开启。
∘ collect-gdb：收集 GDB 堆栈跟踪，需要 gdb 工具。
∘ collect-strace：收集跟踪数据，需要 strace 工具。
∘ collect-tcpdump：收集 tcpdump 数据，需要 tcpdump 工具。
有时候我们会不小心对一个大表进行了 update，比如说写错了 where 条件......
此时，如果 kill 掉 update 线程，那回滚 undo log 需要不少时间。如果放置不管，也不知道 update 会持续多久。
那我们能知道 update 的进度么？
实验
我们先创建一个测试数据库：
快速创建一些数据：
连续执行同样的 SQL 数次，就可以快速构造千万级别的数据：
查看一下总的行数：
我们来释放一个大的 update：
然后另起一个 session，观察 performance_schema 中的信息：
可以看到，performance_schema 会列出当前 SQL 从引擎获取的行数。
等 SQL 结束后，我们看一下 update 从引擎总共获取了多少行：
可以看到该 update 从引擎总共获取的行数是表大小的两倍，那我们可以估算：update 的进度 = (rows_examined) / (2 * 表行数)
????小贴士
information_schema.tables 中，提供了对表行数的估算，比起使用 select count(1) 的成本低很多，几乎可以忽略不计。
那么是不是所有的 update，从引擎中获取的行数都会是表大小的两倍呢？这个还是要分情况讨论的，上面的 SQL 更新了主键，如果只更新内容而不更新主键呢？我们来试验一下：
等待 update 结束，查看 row_examined，发现其刚好是表大小：
那我们怎么准确的这个倍数呢？
一种方法是靠经验：update 语句的 where 中会扫描多少行，是否修改主键，是否修改唯一键，以这些条件来估算系数。
另一种方法就是在同样结构的较小的表上试验一下，获取倍数。
这样，我们就能准确估算一个大型 update 的进度了。
