最近有台MySQL，在运行一段时间后，res和virt内存都会去到很高，res会占到物理内存的90%，最终导致业务异常
期间做过的尝试：
上面的措施都没有用。
下面这个，不确定有没有试过，也记录下吧
mysqldump -q，就是把数据尽快写到磁盘，而不是存在内存最后是同事看监控，发现在凌晨，MySQL备份后，内存才飙升，我们最后定位到MySQL内存异常的原因是以下2个：
mysqldump -d $1 > $1_db_struc.sql解决办法：
MySQL5.6加入了一个把buffer_pool dump到磁盘的功能，加快MySQL重启后，数据的预热速度，我们用的Percona Server 5.5也加入了这个功能主要有以下几点：
#!/bin/bash
# change online
mysql -uroot -pxxx <<EOF
set @@global.innodb_buffer_pool_restore_at_startup=600;
select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA_LRU_DUMP*/;
EOF可以在MySQL启动后，select一个表的数据，然后查看buffer pool的page数量，手动把buffer pool dump到磁盘，再重启MySQL，看它是否会restore
一些命令:
# 查看buffer pool的数据大小
show status like 'innodb_buffer_pool_pages_data';
# 手动dump
select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA_LRU_DUMP*/;
#手动restore
select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRAmysqldump导出数据的时候，加入–innodb-optimize-keys可以使导入时间缩短一半（仅适用于把整个库导出为一个sql的情况），原理是在创建表的时候，只创建主键索引，二级索引在load完数据后再创建
最近有台MySQL，在运行一段时间后，res和virt内存都会去到很高，res会占到物理内存的90%，
期间做过的尝试：
1、用tcpcopy来把生产环境的流量导到测试服，但MySQL内存并无异常
2、将innodb_file_per_table=1修改为innodb_file_per_table=0，运行1天后，内存飙升还是比较厉害
同事看监控，发现在凌晨，MySQL备份后，内存才飙升
最后查找到MySQL内存异常的原因是以下2个：
1、xxx_db下表太多：近2W了
2、由于表太多，${MYSQLDUMP} -uroot -p${MYSQLPASSWORD} -d $1 > “${BACKUPDIR}/$1_db_struc.sql”这个指令把整个库的表结构导出来的时候，估计会把整个结构先写入内存
解决办法：
1、减少表数量
2、不导整个库的结构，一个表一个表地导（这个也是目前的做法），或者直接就不导结构，因为都是一样的