mysqlcpu平均使用率

MySQL是一款常用的关系型数据库管理系统，它的 CPU 平均使用率指的是 MySQL 进程在某一时间段内 CPU 的平均使用率。通常情况下，MySQL CPU 平均使用率应该保持在合理的范围内，过高的 CPU 使用率可能会导致 MySQL 性能下降。

如果你想要查看 MySQL CPU 平均使用率，可以使用以下方法：

使用 MySQL 的状态监控工具：MySQL 提供了一些状态监控工具，如 mysqladmin、mysqltuner 等，这些工具可以帮助你查看 MySQL 的 CPU 使用情况。

如何提高MySQL Limit查询的性能?

在MySQL数据库 *** 作中，我们在做一些查询的时候总希望能避免数据库引擎做全表扫描，因为全表扫描时间长，而且其中大部分扫描对客户端而言是没有意义的。其实我们可以使用Limit关键字来避免全表扫描的情况，从而提高效率。

有个几千万条记录的表 on MySQL 5.0.x，现在要读出其中几十万万条左右的记录。常用方法，依次循环：

select * from mytable where index_col = xxx limit offset, limit

经验：如果没有blob/text字段，单行记录比较小，可以把 limit 设大点，会加快速度。

问题：头几万条读取很快，但是速度呈线性下降，同时 mysql server cpu 99% ，速度不可接受。

调用 explain select * from mytable where index_col = xxx limit offset, limit

显示 type = ALL

在 MySQL optimization 的文档写到"All"的解释

A full table scan is done for each combination of rows from the previous tables. This is normally not good if the table is the first table not marked const, and usually very bad in all other cases. Normally, you can avoid ALL by adding indexes that allow row retrieval from the table based on constant values or column values from earlier tables.

看样子对于 all, mysql 就使用比较笨的方法，那就改用 range 方式？ 因为 id 是递增的，也很好修改 sql 。

select * from mytable where id >offset and id <offset + limit and index_col = xxx

explain 显示 type = range，结果速度非常理想，返回结果快了几十倍。

Limit语法：

SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset

LIMIT子句可以被用于强制 SELECT 语句返回指定的记录数。LIMIT接受一个或两个数字参数。参数必须是一个整数常量。

如果给定两个参数，第一个参数指定第一个返回记录行的偏移量，第二个参数指定返回记录行的最大数目。初始记录行的偏移量是 0(而不是 1)。

为了与 PostgreSQL 兼容，MySQL 也支持句法：LIMIT # OFFSET #。

mysql>SELECT * FROM table LIMIT 5,10//检索记录行6-15

//为了检索从某一个偏移量到记录集的结束所有的记录行，可以指定第二个参数为-1

mysql>SELECT * FROM table LIMIT 95,-1//检索记录行96-last

//如果只给定一个参数，它表示返回最大的记录行数目，换句话说，LIMIT n 等价于 LIMIT 0,n

mysql>SELECT * FROM table LIMIT 5//检索前5个记录行

MySQL的limit给分页带来了极大的方便，但数据量一大的时候，limit的性能就急剧下降。同样是取10条数据，下面两句就不是一个数量级别的。

select * from table limit 10000,10

select * from table limit 0,10

文中不是直接使用limit，而是首先获取到offset的id然后直接使用limit size来获取数据。根据他的数据，明显要好于直接使用limit。

这里我具体使用数据分两种情况进行测试。

1、offset比较小的时候：

select * from table limit 10,10

//多次运行，时间保持在0.0004-0.0005之间

Select * From table Where vid ＞=(Select vid From table Order By vid limit 10,1) limit 10

//多次运行，时间保持在0.0005-0.0006之间，主要是0.0006

结论：偏移offset较小的时候，直接使用limit较优。这个显然是子查询的原因。

2、offset大的时候：

select * from table limit 10000,10

//多次运行，时间保持在0.0187左右

Select * From table Where vid ＞=(Select vid From table Order By vid limit 10000,1) limit 10

//多次运行，时间保持在0.0061左右，只有前者的1/3。可以预计offset越大，后者越优。

首先介绍下 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 工具。

---