MYSQL 内存排查

1.查参数配置

目前积累的使用经验中，存储过程&函数&触发器&视图 在MySQL场景下是不适合的。性能不好，又容易发现内存不释放的问题，所以建议尽量避免.

2.存储过程&函数

3.视图

4.触发器

5.1 总内存使用

5.2 分事件统计内存

5.3 账号级别统计

5.4 线程对应sql语句，内存使用统计

5.5 打开所有内存性能监控，会影响性能，需注意

5.6 系统表内存监控信息

6.top 命令

8.ps命令

9.pmap 命令

pmap是Linux调试及运维一个很好的工具，查看进程的内存映像信息

用法1：执行一段时间记录数据变化，最少20个记录，下面69265是MySQL pid

用法2：linux 命令pmap MySQL pid导出内存，下面69265是MySQL pid

RSS就是这个process实际占用的物理内存。

Dirty: 脏页的字节数（包括共享和私有的）。

Mapping: 占用内存的文件、或[anon]（分配的内存）、或[stack]（堆栈）。

writeable/private：进程所占用的私有地址空间大小，也就是该进程实际使用的内存大小。

1.首先使用/top/free/ps在系统级确定是否有内存泄露。如有，可以从top输出确定哪一个process。

2.pmap工具是能帮助确定process是否有memory leak。确定memory leak的原则：writeable/private (‘pmap –d’输出）如果在做重复的 *** 作过程中一直保持稳定增长，那么一定有内存泄露

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

肯定影响的。

常见查询慢的原因常见的话会有如下几种：

1、没有索引或没有用到索引。

PS：索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表 的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个 *** 作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录 即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。

索引类型：

普通索引：这是最基本的索引类型，没唯一性之类的限制。

唯一性索引：和普通索引基本相同，但所有的索引列只能出现一次，保持唯一性。

主键：主键是一种唯一索引，但必须指定为"PRIMARY KEY"。

全文索引：MYSQL从3.23.23开始支持全文索引和全文检索。在MYSQL中，全文索引的索引类型为FULLTEXT。全文索引可以在VARCHAR或者TEXT类型的列上创建。

2、IO吞吐量小形成了瓶颈。

PS：这是从系统层来分析MYSQL是比较耗IO的。一般数据库监控也是比较关注IO。

监控命令：$iostat -d -k 1 10

参数 -d 表示，显示设备（磁盘）使用状态；-k某些使用block为单位的列强制使用Kilobytes为单位；1 10表示，数据显示每隔1秒刷新一次，共显示10次。

3、内存不足

监控内存使用：vmstat [-n] [延时[次数]]

Memory

swpd: 切换到交换内存上的内存(默认以KB为单位)

• 如果 swpd 的值不为0，或者还比较大，比如超过100M了，但是si, so 的值长期为0，这种情况我们可以不用担心，不会影响系统性能。

free: 空闲的物理内存

buff: 作为buffer cache的内存，对块设备的读写进行缓冲

cache: 作为page cache的内存, 文件系统的cache• 如果 cache 的值大的时候，说明cache住的文件数多，如果频繁访问到的文件都能被cache住，那么磁盘的读IO bi 会非常小。

4、网络速度慢

ping IP -t 查看是否有丢包。

5、一次查询的数据量过大。

比如没有分页查询，一次提取上万条记录。数据库有可能卡死。

---