Linux上MySQL优化提升性能，哪些可以优化关闭NUMA特性？

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官网下载mysql编译好的二进制安装包，在下载页面Select Platform:选项选择linux-generic，然后把页面拉到底部，64位系统下载Linux - Generic (glibc 2.5) (x86, 64-bit)，32位系统下载Linux - Generic (glibc 2.5) (x86, 32-bit)

解压32位安装包:

进入安装包所在目录，执行命令：tar mysql-5.6.17-linux-glibc2.5-i686.tar.gz

复制解压后的mysql目录到系统的本地软件目录:

执行命令：cp mysql-5.6.17-linux-glibc2.5-i686 /usr/local/mysql -r

注意：目录结尾不要加/

添加系统mysql组和mysql用户：

执行命令：groupadd mysql和useradd -r -g mysql mysql

安装数据库：

进入安装mysql软件目录：执行命令 cd /usr/local/mysql

修改当前目录拥有者为mysql用户：执行命令 chown -R mysql:mysql ./

安装数据库：执行命令 ./scripts/mysql_install_db --user=mysql

修改当前目录拥有者为root用户：执行命令 chown -R root:root ./

修改当前data目录拥有者为mysql用户：执行命令 chown -R mysql:mysql data

到此数据库安装完毕

启动mysql服务和添加开机启动mysql服务：

添加开机启动：执行命令cp support-files/mysql.server /etc/init.d/mysql，把启动脚本放到开机初始化目录

启动mysql服务：执行命令service mysql start

执行命令：ps -ef|grep mysql 看到mysql服务说明启动成功，如图

修改mysql的root用户密码，root初始密码为空的：

执行命令：./bin/mysqladmin -u root password '密码'

把mysql客户端放到默认路径：

ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql

有用户在使用 MySQL5.7 的数据库时，遇到 undo 暴涨情况，经排查存在一条慢 SQL 执行了上万秒仍没有结束，导致后续事务产生的 undo 不能清理，越来越多

在线 truncate undo log 已开启，将慢 SQL kill 掉之后，undo 大小超过 innodb_max_undo_log_size 设置的大小，但 undo 文件没有立即收缩

测试参数如下，开启 innodb_undo_log_truncate

模拟 undo 增长，超过 innodb_max_undo_log_size 设置大小

查看官方文档undo清理策略，简单概括为以下：

1、启用 innodb_undo_log_truncate 后，超过 innodb_max_undo_log_size 设置大小的undo表空间被标记为截断

2、被标记的undo表空间的回滚段被设置为不活跃的，不能分配给新的事务

3、purge线程释放不需要的回滚段

4、释放回滚段后，undo表空间被截断为初始大小10M

可以看到在收缩undo大小前，需要purge线程先释放回滚段，这里涉及另一个参数 innodb_purge_rseg_truncate_frequency，默认值128，表示purge线程每调用128次，就释放回滚段一次

此次问题背景中，该参数设置的是默认值

所以为了尽快收缩 undo 文件，我们可以将 innodb_purge_rseg_truncate_frequency 值调小，提高 purge 线程释放回滚段的频率

MySQL8.0 新增支持使用 SQL 语句来管理 undo 表空间

1、需要至少三个活跃的 undo 表空间，因为要保证有两个活跃的 undo 表空间来支持 Automated Truncation

手工创建一个 undo 表空间，必须以 .ibu 结尾

2、手工截断 undo 表空间，需要先将 undo 表空间设置为 inactive

3、手工设置 inactive 后，undo 表空间被标记为截断，purge 线程会增加返回频率，快速清空并最终截断 undo 表空间，状态变为 empty

4、empty 状态的 undo 表空间可以重新激活使用

5、MySQL8.0 支持删除表空间，但前提是该表空间为 empty 状态

---