数据库版本:percona mysql 5.0.67
数据量:670m+
内存大小:16g
innodb buffer pool size:4g
其它回话内存分配并不大，基本在100m以内，并且连接数非常少
服务器负载不高，开启binlog，数据库和程序都已经进行过迁移，问题仍然存在。通过top命令查看mysql占用内存一直在增长，且开始使用swap。
分析排除过程：
1.怀疑到的是innodb内存占用，使用show engine innodb status查看，发现free buffer占很大部分，因此可以判断分配给innodb引擎的内存够用
2.查看回话，回话数基本在3~4个，且回话分配的内存大小与现在mysql占用的回话总和相差很大，因此也不会是回话的问题
3.程序、数据库软件问题。已经迁移过两次，版本与外网一致，问题依旧，因此也排除了这个问题
4.mysql重启后内存释放，因此问题还是在mysql身上，根据网上说的flush tables的做法发现无效，所以也不是打开的表数量过大的问题导致。
就在临时维护前1小时，网上查找案例时，有人说内存表配置不当也有可能导致内存异常，但因为天龙没有用到memory引擎，因此没太在意，但已经山穷水尽，也不知道该做什么，就查了下数据库中innodb以外的表，主要集中在mysql库及information_schema库：
+——————–+—————————————+——–+
| table_schema | table_name | engine |
+——————–+—————————————+——–+
| information_schema | character_sets | memory |
| information_schema | client_statistics | memory |
| information_schema | collations | memory |
| information_schema | collation_character_set_applicability | memory |
| information_schema | columns | myisam |
……
| mysql | help_topic | myisam |
| mysql | time_zone | myisam |
| mysql | time_zone_leap_second | myisam |
| mysql | time_zone_name | myisam |
| mysql | time_zone_transition | myisam |
| mysql | time_zone_transition_type | myisam |
| mysql | user | myisam |
+——————–+—————————————+——–+
因为myisam表不多，而且表都不大，内存分配也没有问题，所以我大概过了一遍，剩下的就是memory 表了。
单独对这些表进行查看，最终发现client_statistics表非常异常，原因是作为内存表查询速度非常慢，，并且会报错，在/tmp/下的一个临时文件需要修复，因此到/tmp目录下进行查看，基本就定位到问题了：导出的临时表约为7~8g！
查看表数据基本不可能，因此在维护时，重启了数据库，并且查看了里面的数据，发现数据增长非常快，里面记录的都是客户端的连接记录，比较特别的就是主机名显示不全。因此我们选择将主机名改成ip的形式，用于定位出问题的服务器(当时还在怀疑是程序连接中断导致记录数增长)。但修改完后发现问题消失了，该台服务器与其他服务器区别，问题表的数据量也正常了，因此我们定位问题到了主机名上，我进行了一下实验：
现在有245、246两台机器：
246是客户端、245是服务器端
(root:245:thu apr 24 16:37:28 2014)[information_schema]> select count(*) from client_statistics;
+———-+
| count(*) |
+———-+
| 2 |
+———-+
1 row in set (0.00 sec)
可以看到表里面的数据是2条
[dbatlbb@ ~]$ mysql -h 245 -uwuwl_test -p
mysql: can’t create/write to file ‘/home/mysql/query.log’ (errcode: 13)
error logging to file ‘/home/mysql/query.log’
logging to file ‘/home/dbatlbb/mysql/query.log’
enter password:
welcome to the mysql monitor. commands end with ; or /g.
your mysql connection id is 556
server version: 5.0.67-percona-highperf-log source distribution
type ‘help;’ or ‘/h’ for help. type ‘/c’ to clear the buffer.
(wuwl_test:${hostname}:thu apr 24 16:39:19 2014)[(none)]> show processlist;
+—–+———–+———————————+——+———+——+——-+——————+
| id | user | host | db | command | time | state | info |
+—–+———–+———————————+——+———+——+——-+——————+
| 556 | wuwl_test | gs_438_friuha_fgesihs_fsd:50768 | null | query | 0 | null | show processlist |
+—–+———–+———————————+——+———+——+——-+——————+
1 row in set (0.00 sec)
连接了一下，并进行了一次查询操作
(root:nj-245:thu apr 24 16:38:38 2014)[information_schema]> select count(*) from client_statistics;
+———-+
| count(*) |
+———-+
| 5 |
+———-+
1 row in set (0.01 sec)
发现数据有增长，再次进行几次查询，发现每次查询都会有增长，这个正常现象么?我修改了下主机名进行了再次查询，发现表数据不再增长。
修改方法：主机名需要小于16字节。
目前在5.5和5.6版本上进行了测试，发现这个表数据为空，因此这个问题可能是在5.0版本上面的一个bug。
总结：
本次问题现象主要是：内存异常被mysql占用不释放并持续上涨，更换过程序和数据库服务器仍没有效果，服务器数据量很小，innodb buffer空闲很大。
问题原因：由于数据库自身的统计数据表information_schema.client_statistics 数据量过大导致内存占用，client_statistics是一张内存表。
问题处理方法：由于client_statistics表里面的host列是16个字节的，因此如果主机名过长，会导致客户端每一次的操作都会在表里面新增一条数据，无论操作是否成功。因此只需要修改连接的主机名不要超过16位就不会导致内存占用不释放的问题。
思考：修改了默认的东西，需要在小部分服务器上进行测试，并详细记录修改后的异常，用于对比不同服务器之间的差别。
延伸：
client_statistics 用于统计客户端连接，目前5.5、5.6以及maria已经将client字段升级为64个字节，且该统计功能默认关闭，所以如果大家有统计需要，一定要记得主机名不能大于64个字节！