13518219792
首先在sql中查询计划事件的状态：SHOW VARIABLES LIKE 'event_scheduler'
成都创新互联公司，为您提供网站建设、成都网站制作、网站营销推广、网站开发设计，对服务封阳台等多个行业拥有丰富的网站建设及推广经验。成都创新互联公司网站建设公司成立于2013年,提供专业网站制作报价服务,我们深知市场的竞争激烈，认真对待每位客户，为客户提供赏心悦目的作品。 与客户共同发展进步，是我们永远的责任！
如果返回的是off表示当前是关闭状态，如果是on当前已经开启了计划任务。
在mysql程序的目录下找到my.ini文件，添加一个项：event_scheduler = 1
保存后重启mysql服务即可，重启服务可以在服务管理里面找到
也可以用脚本来实现：
mysql event_scheduler
开启event_scheduler sql指令：
SET GLOBAL event_scheduler = ON;
SET @@global.event_scheduler = ON;
SET GLOBAL event_scheduler = 1;
SET @@global.event_scheduler = 1;
相反，关闭event_scheduler指令：
SET GLOBAL event_scheduler = OFF;
SET @@global.event_scheduler = OFF;
SET GLOBAL event_scheduler = 0;
SET @@global.event_scheduler = 0;
1、进入数据库
MySQL use cpc;
Database changed
2、输入 show events\G; 指令；
mysql show events\G;
现象是，系统里的java连接mysql超时了，
于是去mysql的机器，查看/var/log/messages日志，查对应的时间点的情况
发现mysql被阻塞了blocked for more than 120 seconds，mysql的io非常之高，用top查看系统的负载也到达了50的样子
用mpstat查看cpu情况
好明显，都在等io
用iostat查看io情况，%util的值，一直在80%，99%之间变化
以为磁盘有问题，用dd测下速看看
从上面的结果看，也还好，没问题
以为可能磁盘有坏道，用下面命令也扫了一遍，没问题
结果也没有坏的块，这个过程，很耗时。
用show processlist命令查看mysql正在忙着什么，一看，也没什么任务在执行的
想看看mysql，研究写哪个文件时，最耗时的
从上面结果来看，xxl_job是最耗时的。知道点眉目了，因为公司的定时任务是用的xxljob，定时任务里，有每几秒执行的任务，我猜它的日志记录一定很大，于是查看一下
我的天，这个表的记录有千万！！！这些记录，没做定时任务来清理，由于都是一些没用的记录，所以这个表的数据我全清了
清了之后，再用iostat查看
%util一下子就降下来了，用iotop查看mysql进程的io也下降了
cpu的iowait也下降了
定义一个事件，让mysql定时清理30天前的日志记录
记录一下，希望对有需要的朋友也起一点提示
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’输出）如果在做重复的操作过程中一直保持稳定增长，那么一定有内存泄露
