【IT168 专稿】本文的作者Peter Zaitsev在2006年创建Percona，精通数据库内核、计算机硬件和应用扩展。他在文中表示，最期待MySQL 5.7能够在内存管理和监测方面有所改进。以下为文章正文：

        随着MySQL 5.6中的新特性Performance Schema的引入(简介:提供新功能包括：表锁、表I/O 以及表锁等待,详细请参考网站),能让开发者更好地了解性能的瓶颈,以及CPU资源的耗费情况(尽管Performance Schmea没能直接将cpu的情况考虑在内,但其实可以通过等待信息等相对容易地推算出来)。而我们一直对MySQL中的内存使用的这个部分依然认识不多，这也是我们一直期望在2013年，MySQL能做的更好的。

　　作为DBA或者开发者，经常会为遇到一些关于MySQL的内存的问题而发愁，比如在global buffers中只有几GB的内存，但却要面对日益增长的内存需求，无论是用户的变量，复杂的存储过程或者其他都需要占用这些内存，不仅用户的连接的内存连接情况较难看到，而且很多全局内存分配都是很难可视化地看到。当然，对于Innodb Buffer Pool或者Query Cache的内存分配我们都比较容易去了解，但对于例如Table Cache这样的内存分配情况，我们大多只能进行一些猜测。

　　缺少合适的内存审计不仅对操作上带来不方便，而且对于QA来说，很难去确保各类数据库操作中内存的分配是否恰当。比如，如果一些INFORMATION_SCHEMA查询占用了数GB内存，造成时间很长，但这个却不能认为是内存泄露，因为在操作完毕后内存会释放。

　　作为开发者，对新的版本的MySQL在内存管理上，有什么期待呢?本人认为应该像5.6版本中Performance Schema中的“wait names”一样，就内存的分配目标而言，可以建议分成“Prepared Statement Cache”，“Table Cache”等等。对于全局池(global pools)我们需要的是每一个连接所耗费的内存以及总共所有连接所耗费的内存，这样的好处是能直观看到哪些连接耗费最多的内存。

　　有一点需要注意的是，内存的分配是会经常变动的，大部分的内存分配在非常短的时间内完成并且不是十分直观。为了帮助捕捉各类内存分配的情况，建议新版本中不仅是跟踪当前的内存分配，更应该加上所有的内存分配总量情况，并且可以根据需要进行内存的动态分配。

　　假如这样的功能在新的版本中得以实现，则不仅会帮助DBA去更好地去管理配置内存的分配，同时也相信和Performance Schema一样，能更好帮助DBA去发现更多性能上的瓶颈，比如发现是否浪费了内存而没能更好利用。同样，对于QA,有了这样的内存统计功能的话，可以更好在每次测试后，发现内存在使用上的问题，比如新的代码申请了不必要的内存而造成的问题。

　　如果在新版本中MySQL内存统计方面增强的话，对于运营商或者云服务商来说也是件好事，因为可以更精确地监视用户在MySQL上的内存使用情况。

　　现在MySQL 5.6版本已经发布，因此希望在新的5.7版本中，能在内存管理和监控方面有新的大动作，或者起码能够列入发布计划，如果MySQL社区版本暂时没计划的话，希望MariaDB分支能有所动作。