13518219792
我们仍然使用两个会话，一个会话 run，用于运行主 SQL；另一个会话 ps，用于进行 performance_schema 的观察：
目前成都创新互联公司已为上千的企业提供了网站建设、域名、网站空间、网站运营、企业网站设计、西区网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
主会话线程号为 29，
将 performance_schema 中的统计量重置，
临时表的表大小限制取决于参数 tmp_table_size 和 max_heap_table_size 中较小者，我们实验中以设置 max_heap_table_size 为例。
我们将会话级别的临时表大小设置为 2M（小于上次实验中临时表使用的空间），执行使用临时表的 SQL：
查看内存的分配记录：
会发现内存分配略大于 2M，我们猜测临时表会比配置略多一点消耗，可以忽略。
查看语句的特征值：
可以看到语句使用了一次需要落磁盘的临时表。
那么这张临时表用了多少的磁盘呢？
我们开启 performance_schema 中 waits 相关的统计项：
重做实验，略过。
再查看 performance_schema 的统计值：
可以看到几个现象：
1. 临时表空间被写入了 7.92MiB 的数据。
2. 这些数据是语句写入后，慢慢逐渐写入的。
来看看这些写入操作的特征，该方法我们在 实验 03 使用过：
可以看到写入的线程是 page_clean_thread，是一个刷脏操作，这样就能理解数据为什么是慢慢写入的。
也可以看到每个 IO 操作的大小是 16K，也就是刷数据页的操作。
结论：
我们可以看到，
1. MySQL 会基本遵守 max_heap_table_size 的设定，在内存不够用时，直接将表转到磁盘上存储。
2. 由于引擎不同（内存中表引擎为 heap，磁盘中表引擎则跟随 internal_tmp_disk_storage_engine 的配置），本次实验写磁盘的数据量和 实验 05 中使用内存的数据量不同。
3. 如果临时表要使用磁盘，表引擎配置为 InnoDB，那么即使临时表在一个时间很短的 SQL 中使用，且使用后即释放，释放后也会刷脏页到磁盘中，消耗部分 IO。
Linux 进程通过 C 标准库中的内存分配函数 malloc 向系统申请内存，但是到真正与内核交互之间，其实还隔了一层，即内存分配管理器(memory allocator)。常见的内存分配器包括：ptmalloc(Glibc)、tcmalloc(Google)、jemalloc(FreeBSD)。MySQL 默认使用的是 glibc 的 ptmalloc 作为内存分配器。
内存分配器采用的是内存池的管理方式，处在用户程序层和内核层之间，它响应用户的分配请求，向操作系统申请内存，然后将其返回给用户程序。
为了保持高效的分配，分配器通常会预先向操作系统申请一块内存，当用户程序申请和释放内存的时候，分配器会将这些内存管理起来，并通过一些算法策略来判断是否将其返回给操作系统。这样做的最大好处就是可以避免用户程序频繁的调用系统来进行内存分配，使用户程序在内存使用上更加高效快捷。
关于 ptmalloc 的内存分配原理，个人也不是非常了解，这里就不班门弄斧了，有兴趣的同学可以去看下华庭的《glibc 内存管理 ptmalloc 源代码分析》【文末链接】。
关于如何选择这三种内存分配器，网上资料大多都是推荐摒弃 glibc 原生的 ptmalloc，而改用 jemalloc 或者 tcmalloc 作为默认分配器。因为 ptmalloc 的主要问题其实是内存浪费、内存碎片、以及加锁导致的性能问题，而 jemalloc 与 tcmalloc 对于内存碎片、多线程处理优化的更好。
目前 jemalloc 应用于 Firefox、FaceBook 等，并且是 MariaDB、Redis、Tengine 默认推荐的内存分配器，而 tcmalloc 则应用于 WebKit、Chrome 等。
生产环境中，MySQL 不经意间吃掉全部的内容，然后开始吃掉 SWAP，性能一降再降，怎么办？
可以从下面三点查看原因：
MySQL 使用内存，有两个途径。
永久占用的内容
比如全局缓冲区（Global Buffer）类别，是在服务器启动期间从操作系统获得的，不会释放到任何一个别的进程。
动态请求的内存
线程缓冲区由MySQL使用，它是在处理新查询时从操作系统请求的内存。在执行查询之后，该内存被释放回操作系统。
这意味着 MySQL 的内存使用，是 全局缓冲区 加上 线程缓冲区 以及 允许的最大连接数 。
对于专用数据库服务器，该值需要保持在服务器内存的90%以下。在共享服务器的情况下，它应该保持在服务器内存的50%以下。
检查一下 MySQL 设置，有助于确定内存使用情况，从而为 MySQL 分配合适的值。
一个近似的公式：
当网站受到攻击时，有可能在短时间内建立异常高的连接数量。MySQL 中的 PROCESSLIST 可用于检测顶级用户并阻止对滥用连接的访问。
找出查询需要很长时间才能执行的语句，因为这些查询需要进一步优化服务器才能更好地执行，可以通过服务器查询日志进行识别。由于查询速度慢，导致磁盘读取较多，导致内存和CPU使用率较高，影响服务器性能。
最后，到了加内存条的时候了。虽然在优化数据库设置之后，服务器会不断地路由到使用交换内存，但也必须增加内存。俗话说：“巧妇难为无米之炊”，就是这个意思。
上面说的这些方向，大家可以在实际操作中验证体会，希望大家在数据库优化的路上，麻溜顺畅，砥砺前行。
