今天明月给大家分享一下 WordPress 、Typecho 站点的 MySQL/MariaDB 数据库优化，无论你的站点采用是 WordPress 还是 Typecho，都要用到 MySQL/MariaDB 数据库，我们以 MySQL 为主（MariaDB 其实跟 MySQL 基本没啥大的区别，所以同样都适用。）给大家讲解一下数据库的优化。
在【WordPress 到底能不能承受百万级内容？】一文里，明月给大家讲过 WordPress 网站系统能处理的内容数量其实是取决于 MySQL 的部署的，可见 MySQL 数据库对于 WordPress 站点的重要性，加上目前大部分的 WordPress 站点数据库都是以本地部署（localhost，也就是数据库和网站在同一个服务区上）的形式使用的，所以优化 MySQL 就更加的必不可少了，结合明月多年代维的经验总结出如下几条 MySQL 数据库优化的建议：
一、关闭 MySQL 的日志
MySQL 中的 binlog 日志记录了数据库中数据的变动，便于对数据的基于时间点和基于位置的恢复，但是 binlog 也会日渐增大，占用很大的磁盘空间，同时还会带来一定的 I/O 压力，理论上来说只要我们不使用 MySQL 的主从复制基本很少用到 binglog 日志，所以一般明月都会建议关闭 MySQL 的日志，只需要把 /etc/my.cnf 文件里：
log-bin=mysql-bin
binlog_format=mixed
这两行给注释掉即可，如下图所示：
#log-bin=mysql-bin
#binlog_format=mixed
然后保存退出，重启 MySQL 进程就行了。
注意，当你要使用 MySQL 的主从复制的时候一定要记得开启 MySQL 日志哦！
二、开启 MySQL 的查询缓存
MySQL 和 MariaDB 都是支持"查询缓存"功能，并且启用 MySQL 查询缓存可以极大地减低数据库服务器的 CPU 使用率，实际使用情况是：开启前 CPU 使用率 120%左右，开启后降到了 10%。具体开启方法可以参考【启用 MySQL 和 MariaDB 查询缓存】一文，需要注意的是这个方法适合没有使用 Memcached、Redis 缓存数据库查询的时候使用，否则就重复了，一定要注意哦，跟下面讲的第四条冲突了，比较适合熟悉 MySQL 命令的运维人员使用，配合下面第三条效果更加，安全性也更好。建议大家根据自己服务器部署和使用情况灵活的选择和使用。
三、调整数据库 InnoDB 存储引擎的关键参数
一般我们的 MySQL 数据库在编译安装部署的时候都会让选择数据库存储引擎，比较多的选择是 InnoDB 存储引擎，这时候我们就可以在/etc/my.cnf 文件里调整 innodb_buffer_pool_size 和 innodb_buffer_pool_instances 参数来优化 MySQL 的性能。
Innodb_buffer_pool_size
innodb_buffer_pool_size 是 InnoDB 存储引擎的关键参数，用于配置 InnoDB 缓冲池的大小。
默认大小为 128M，但您应该根据服务器的物理内存进行调整。
在专用数据库服务器上，可以将缓冲池大小设置为服务器物理内存的 80%。
可以动态设置，允许在不重新启动服务器的情况下调整缓冲池的大小。
Innodb_buffer_pool_instances
innodb_buffer_pool_instances 是用于配置多个缓冲池实例的参数。
默认情况下，它设置为 1，表示只有一个缓冲池实例。
当缓冲池大小大于 1G 时，将innodb_buffer_pool_instances设置为大于 1 的值可以提高服务器的可扩展性。
大的缓冲池可以减小多次磁盘 I/O 访问相同的表数据。
配置示例
假设您的服务器物理内存足够，您可以设置innodb_buffer_pool_size为 1G，并将innodb_buffer_pool_instances设置为 1。
请注意，innodb_buffer_pool_size必须是innodb_buffer_pool_instances的倍数。
在线调整
您可以使用以下语句在线调整 InnoDB 缓冲池大小：
SET GLOBAL innodb_buffer_pool_size=3221225472;--设置为 3G
监控在线缓冲池调整进度：
SHOW STATUS WHERE Variable_name='InnoDB_buffer_pool_resize_status';
性能验证
您可以通过分析 InnoDB 缓冲池的性能来验证配置是否合适。
计算 InnoDB 缓冲池命中率：
Performance=innodb_buffer_pool_reads/innodb_buffer_pool_read_requests*100
如果命中率低于 99%，可以考虑增加innodb_buffer_pool_size。
可见 innodb_buffer_pool_size 和 innodb_buffer_pool_instances 参数的调整是要根据实际调试来选择的，比较适合专业运维人员选择使用，新手可以根据服务器物理内存大小适当的加大 innodb_buffer_pool_size 参数即可，
四、使用 Memcached 把数据库查询放到内存中
Memcached 其实是非常适合 LNMP 环境的站点服务器使用的，主要原因就是其简单高效的内存利用率了，这正是我们需要的，也是 Memcached 加速原理的主要表现了。Memcached 就是把需要 CPU 计算的重复性的东西都有序的保存在物理内存里以实现可以被最快的速度重复调用，让 CPU 能有更多空闲时间处理其他的运算请求，所谓的加速其实就是体现在这里而已，说白了 Memcached 是变相的给 CPU 加速了，知道 Memcached 这个原理其实就足够了。
同时，明月要再次强调一下，像我们这种站点服务器使用 Memcached 就足够了，真心没有必要选择 Redis 的，因为 Redis 更多的时候比较适用于独立数据库服务器或者集群数据库服务器上使用，具体可以参考【理智冷静的使用 Memcached 或者 Redis】一文，有专门详细的论述。
五、搭建数据库专用服务器或者云数据库
如果你的 WordPress 站点需要处理十万、百万级的内容量就要像【WordPress 到底能不能承受百万级内容？】一文里说的，必须搭建一个或者 N 个独立的数据库服务器，每个独立的数据库服务器都充分的利用物理内存缓存查询记录再通过内网跟网站服务器通信实现数据库主从复制和负载均衡来缓解数据库的实时查询压力，基本上这种部署都属于是企业级的了，成本和维护压力也是很大的，比较适合拥有专业的运维技术团队了，就不属于是咱们个人网站的范畴了。
其实 MySQL 数据库的优化无非就是缓存数据库查询记录到 Linux 物理内存里，减少 MySQL 实时查询的频率，对于我们很多个人博客站点来说，512MB 物理内存基本就可以缓存 99%以上的 MySQL 实时查询记录了，更多的时候往往都是用不完，除非你用的插件、主题里有频繁的数据库读写操作才会造成 MySQL 负载飙升的现象，所以慎用来历不明和不负责任的插件和主题也是优化数据库性能要考虑的。