现象：

　　阿里金融某业务的MySQL机器的内存每隔几天会增长，涨上去后，却不下来。累积后内存爆掉。

　　分析：

　　此业务是间隔的对MySQL有大访问，其它时间几乎无访问。排查发现，内存涨时，一般会有MySQL读非常大，主要是InnoDB_DATA_READS。

　　结合此时的特性，业务同学给出此时的主要场景：

　　1、14个线程并发；

　　2、写入数据流程：先查询再update；

select pid，value from tableName where id=?;
查不到“id&pid”的记录，执行如下语句
insert into tableName values ( id，pid，value，now() ) on duplicate key update value=values(value) ;
查到“id&pid”的记录，执行如下
update tableName set value= ? where id=? and pid=?;

　　在分析过程，我们走了些弯路。现在回想，我们可能会从如下几个方面去思考：

　　1、近期升级过kernel，典型的阿里分库分表集群，其中一台升级未升级。所以，新版本内核相关性不大。

　　2、innodb内部统计的内存使用量，没有发现异常。

　　3、NUMA开关导致swap。这是MySQL swap中经常会讨论到的，但这几台没有开（线上也全部是关掉的）。

　　4、临时表、memory引擎表，可能会消耗大量的服务器端的内存，但业务没有用到或生成临时表。

　　5、连接所消耗内存。类似key_buffer_size等每个线程所占有的，是我们格外要注意的，但很明显，这点可以否定，因为并发连接一直很小。

　　6、table cache相关的内存。这点实现证明，效果非常明显，是我们排查问题的突破点。

　　7、真正的mysqld内存泄漏。结合业务的特性，在buglist中发现这个问题在很久很久之前确实存在并早已fix掉。

　　执行FLUSH TABLES发现mysqld的RSZ直接减少10G~

　　flush之前：

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3018 mysql 20 0 44.2g 41g 4232 S 0.0 86.8 981:52.36 /u01/mysql/libexec/mysqld

$ free -m
total used free shared buffers cached
Mem: 48384 46335 2048 0 344 2896
-/+ buffers/cache: 43094 5289
Swap: 8191 8 8183

　　flush之后：

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3018 mysql 20 0 34.7g 30g 4248 S 0.3 65.5 981:55.64 /u01/mysql/libexec/mysqld

$ free -m
total used free shared buffers cached
Mem: 48384 36010 12373 0 345 2898
-/+ buffers/cache: 32766 15617

　　innodb层状态几乎没有变化：

———————-
BUFFER POOL AND MEMORY
———————-
Total memory allocated 26361200640; in additional pool allocated 0
Dictionary memory allocated 7723336
Buffer pool size 1572863
Free buffers 1
Database pages 1556426
Old database pages 574520
Modified db pages 4
Pending reads 0

　　解决方法：

　　定时在业务低峰时flush tables或将相关的参数（table_open_cache 和 table_definition_cache）改小（从2048到512或更小）。