MySQL内存分配构造
定位这个问题，先理解一下MySQL的内存分配知识。
MySQL的内存分配分为两部分，一部分是启动之初就分配的，紧张是buffer_pool_size，key_buffer_size(本例256M)等。还有一部分是每个连接建立并实行查询等操作时分配的。https://dev.mysql.com/doc/refman/5.6/en/memory-use.html
MySQL的内存分配分为两部分，一部分是启动之初就分配的，紧张是buffer_pool_size，key_buffer_size(本例256M)等。还有一部分是每个连接建立并实行查询等操作时分配的。https://dev.mysql.com/doc/refman/5.6/en/memory-use.html
每个连接分配的（当有相应的SQL操作时，非活动线程占用的内存很小）(read_buffer_size+read_rnd_buffer_size+sort_buffer_size+thread_stack+join_buffer_size+binlog_cache_size)=8M+32M+8M+256K+2M+32K~=51M
但是，须要把稳的是，每个连接。有须要的时候会动态的扩展到max_allowed_packet，也即64M。大概这便是文件中很多64M的内存块分配的缘故原由吧？
我猜想是这样，但是实际上确不太精确。由于Threads_connected | 75， Threads_created | 622，状态信息显示所有的连接创建数统共才622个，而且按文档所述连接所用的内存该当紧张按照活动的连接进程来打算。 现网即时状态显示，活动连接总计才 Threads_running | 3 个。
max_allowed_packet = 64MEach thread that the server uses to manage client connections requires some thread-specific space. The following list indicates these and which system variables control their size:A stack (thread_stack)A connection buffer (net_buffer_length)A result buffer (net_buffer_length)The connection buffer and result buffer each begin with a size equal to net_buffer_length bytes, but are dynamically enlarged up to max_allowed_packet bytes as needed. The result buffer shrinks to net_buffer_length bytes after each SQL statement. While a statement is running, a copy of the current statement string is also allocated.When a thread is no longer needed, the memory allocated to it is released and returned to the system unless the thread goes back into the thread cache. In that case, the memory remains allocated.
注：还有上面所述的关于read_buffer_size, read_rnd_buffer_size根据我的履历最大只能配置2M旁边。太大了，非但不会提升性能，还会影响性能。
至于缘故原由，记得是在某篇文章里面提到过。不太记得出处在哪了，等我找到了再更新。
但这个参数，我是不打算改了。由于是现网，还有这是客户系统，就算有再充分的缘故原由，没有严重问题也不可能接管你的建议修正的。
用PMAP查看内存详细分配除了Buffer pool预先分配的内存230G是在已知的情形下。内存PMAP统计信息显示个中有1659个64M=104G的内存块分配。问题该当便是出在这里，到底是什么导致很多不同的64M的内存块分配，而且分配后还没有开释？
下一步对策
从前面的剖析来看，没有任何一点能阐明问题发生的根本缘故原由。我预测问题有可能是内存透露，大概是内存未开释。
那接下来，我们该怎么办呢？目前来看，我险些没有办法。
内请安题的定位工具，由于现网无法利用。Valgrind
实在还可以查询一下performance_schema关于内存的统计信息。但可惜这个是5.7之后的版本才有的功能。现网5.6版本不支持。
末了的办法：1）在实验室搭建一个和现网一样的环境（数据一样）。但没有流量数据，可能也难以复现问题。2）升级到5.7，反正早晚都要升级的。升级后，关于内存这一块就可以查看更多的信息了。
注：关于内存不开释我也疑惑过有可能是OS的问题，比如说solaris系统便是如此（属于solaris系统的正常征象）。https://bugs.mysql.com/bug.php?id=77616
Solaris系统下，当内存被进程主动开释时，OS不会回收内存到OS，只会标记内存为未利用，等下次进程再须要时再指配给进程，这便是所谓内存重用。表向为进程占用内存一贯坚持高位不会低落。而Redhat, centos是会把内存回收给OS，表向为进程占用内存下将。现网的机器是centos核的，该当不会有此问题。
MySQL 5.7 performance_schema 内存查询其它检讨项
检讨是否有利用内存表，结果是没有(由于只有系统虚内存表)select from information_schema.tables where engine='MEMORY‘
检讨performance_schema占用内存，结果显示为约为761MSHOW ENGINE PERFORMANCE_SCHEMA STATUSType: performance_schemaName: performance_schema.memoryStatus: 798686336167 rows in set (0.00 sec）
白高兴溘然有同事见告我，现网还大量利用了存储过程。这个是我之前忽略的一点。
我一查，是不是有存储过程的Memory leak的BUG？
结果真有。我兴冲冲的用测试机器测试了一下，结果是去世活不涌现我所期待的征象。
再一查，这个BUG，居然在目前利用的版本之前已经修复了。
https://bugs.mysql.com/bug.php?id=76349
后续问题定位两天无果。隔了一个周末来看，居然见告我系统被Monitor重启了，问题没了。
只能等待下次涌现问题再说了。
虽然没有定位出问题，但过程也还是很有参考意义的。
问题每天有，天下还是转。不说了，得去别的地方搬砖了。
