62. MySQL Server 优化

上一小节我们介绍了 SQL 语句的优化思路，接下来我们继续从实战角度，从安装、日志、内存、并发四个方面学习 MySQL Server 的优化方法。

1. 安装配置优化

1.1 版本选择

一般推荐选择二进制发行版，原因有如下好处：

• 安装方式简单，可以快速完成部署；
• 经过 MySQL 官方的测试、验证和编译，稳定性较好。

1.2 关闭 numa

--以 CentOS 6 为例，在 kernel 一行后面添加 numa=off
vi /boot/grub/grub.conf

1.3 limits.conf 配置

vi /etc/security/limits.conf
mysql soft nofile 65535
mysql hard nofile 65535
mysql soft nproc 65535
mysql hard nproc 65535

1.4 关闭大页内存

echo "never" > /sys/kernel/mm/transparent_hugepage/enabled
echo "never" > /sys/kernel/mm/transparent_hugepage/defrag

2. 日志配置优化

2.1 innodb_flush_log_at_trx_commit 和 sync_binlog

innodb_flush_log_at_trx_commit 和 sync_binlog 这两个参数是控制 MySQL 磁盘写入策略以及数据安全性的关键参数。

innodb_flush_log_at_trx_commit：

• 0：参数值为 0 时，由 mysql 的 main_thread 每秒将存储引擎 log buffer 中的 redo 日志写入到 log file，并调用文件系统的 sync 操作，将日志刷新到磁盘。
• 1：参数值为 1 时，每次事务提交时，将存储引擎 log buffer 中的 redo 日志写入到 log file，并调用文件系统的 sync 操作，将日志刷新到磁盘。
• 2：参数值为 2 时，每次事务提交时，将存储引擎 log buffer 中的 redo 日志写入到 log file，并由存储引擎的 main_thread 每秒将日志刷新到磁盘。

sync_binlog：

• 0：参数值为 0 时，存储引擎不进行 binlog 的刷新到磁盘，而由操作系统的文件系统控制缓存刷新。
• 1：参数值为 1 时，每提交一次事务，存储引擎调用文件系统的 sync 操作进行一次缓存的刷新，这种方式最安全，但性能较低。
• n：当提交的日志组=n 时，存储引擎调用文件系统的 sync 操作进行一次缓存的刷新。

innodb_flush_log_at_trx_commit 和 sync_binlog 都为 1 时是最安全的，在 MySQL 服务崩溃或服务器 crash 的情况下，binary log 只有可能丢失最多一个语句或者一个事务，但双 1 模式也是最慢的，会导致频繁的 IO 操作。

实际使用时，需要综合考量这两个参数，可以针对不同的业务场景进行压力测试，找到平衡点。

2.2 innodb_log_buffer_size

innodb_log_buffer_size 是 InnoDB 重做日志的缓存池大小，默认是 8MB。如果有大量更新操作，可以适当增加其大小，避免过多的磁盘操作。

3. 内存优化

3.1 innodb_buffer_pool_size 的设置

innodb_buffer_pool_size 是用来缓存 InnoDB 的数据和索引的内存空间。在专用的数据库服务器上，一般分配 75% 的内存给到 InnoDB 的缓存池。

innodb buffer pool 的使用情况可以通过如下命令查看：

mysql> show status like '%innodb_buffer_pool%';
+---------------------------------------+-----------+
| Variable_name                         | Value     |
+---------------------------------------+-----------+
| Innodb_buffer_pool_resize_status      |           |
| Innodb_buffer_pool_pages_data         | 5123      |
| Innodb_buffer_pool_bytes_data         | 83935232  |
| Innodb_buffer_pool_pages_dirty        | 0         |
| Innodb_buffer_pool_bytes_dirty        | 0         |
| Innodb_buffer_pool_pages_flushed      | 284       |
| Innodb_buffer_pool_pages_free         | 125933    |
| Innodb_buffer_pool_pages_misc         | 0         |
| Innodb_buffer_pool_pages_total        | 131056    |
| Innodb_buffer_pool_read_ahead_rnd     | 0         |
| Innodb_buffer_pool_read_ahead         | 0         |
| Innodb_buffer_pool_read_ahead_evicted | 0         |
| Innodb_buffer_pool_read_requests      | 10187     |
| Innodb_buffer_pool_reads              | 5056      |
| Innodb_buffer_pool_wait_free          | 0         |
| Innodb_buffer_pool_write_requests     | 2575      |
+---------------------------------------+-----------+
18 rows in set (0.03 sec)

可以计算出缓存池的命中率为：

Innodb_buffer_pool_read_hits = (( 1 - Innodb_buffer_pool_reads ) / Innodb_buffer_pool_read_requests ) * 100%

如果命中率太低，这时就需要考虑增加 innodb_buffer_pool_sized 的值了。

4.并发优化

4.1 max_connections

max_connections 表示连接到 MySQL 的最大会话数量。一般业务系统，设置成 500-1000 足够使用。

可以通过如下语句调整 max_connections 的大小：

• 临时：在 MySQL 中直接用命令行执行：

  mysql> show variables like 'max_connections';
  +--------------------------+-------+
  | Variable_name            | Value |
  +--------------------------+-------+
  | max_connections          | 500   |
  +--------------------------+-------+
  1 row in set (0.00 sec)
  
  mysql> set global max_connections=1000;
  Query OK, 0 rows affected (0.00 sec)
  

• 永久：将以下参数添加至配置文件 my.cnf，并重启 MySQL：

  max_connections=1000
  

4.2 thread_cache_size

thread_cache_size 表示缓存一定数量的线程以备重用，可以加快连接 MySQL 的速度。

那么如何判断 thread_cache_size 的设置是否合理呢？通过如下公式计算 thread cache 的命中率，一般命中率高于 90% 才是合理的。

thread_cache_hits =  (( 1 - Thread_created ) / connections ) * 100%

5. 小结

本小节主要介绍了 MySQL Server 优化的四种方法：

1. 安装配置优化；
2. 日志配置优化；
3. 内存优化；
4. 并发优化。

MySQL Server 的优化其实主要是参数的优化调整。一般情况下，参数优化并不能带来质的飞跃，除非原来的参数设置非常不合理。为了减少性能问题，我们应该在系统设计和开发阶段下功夫。