MariaDB 10.6性能调优实战：2核3.5G内存服务器轻松应对1.5万日IP网站流量

作为一名站长，你是否曾遇到过这种情况：服务器配置不算太低，但随着网站流量增加，WordPress后台变得越来越慢，甚至前台页面加载也需要好几秒？如果你使用的是阿里云ECS 2核3.5G内存，并且运行着多个WordPress网站，那么这篇MariaDB 10.6性能调优指南正是你需要的。

为什么选择MariaDB 10.6

当初我从MySQL转向MariaDB，纯粹是因为听说它性能更好。事实证明，这个决定是正确的。MariaDB不仅是MySQL的替代品，更是性能优化的增强版。特别是在10.5和10.6版本中，引入了更多性能改进特性，对WordPress这种数据库密集型的应用来说，效果尤为明显。

记得有一次，我把一个日IP 5000的WordPress站点从MySQL 5.7迁移到MariaDB 10.5，页面加载时间从20多秒降到了3秒内。而MariaDB 10.6在查询优化和资源管理方面又有了显著提升，特别适合我们这种资源有限的云服务器环境。

内存与缓冲区优化

数据库性能调优，首先得从内存配置开始。尤其是在我们这种2核3.5G内存的有限资源环境下，合理分配内存至关重要。

InnoDB缓冲池配置

InnoDB缓冲池是MariaDB性能的核心，它负责缓存数据和索引。如果设置过小，会导致频繁的磁盘I/O，极大影响性能。

根据经验，InnoDB缓冲池应设置为系统内存的50%-80%。对于我们3.5G内存的服务器，可以这样配置：

innodb_buffer_pool_size=2G

但要注意，如果使用MariaDB 10.4.3或更早版本，分配的内存实际会比指定值大约10%。另外，如果可能，将innodb_buffer_pool_instances设置为2，这样可以提高并发性能。

临时表和排序缓冲区

WordPress的很多查询都会用到临时表和排序操作，因此这些缓冲区的设置也很重要：

tmp_table_size=512M
max_heap_table_size=512M
sort_buffer_size=10M

需要注意的是，tmp_table_size和max_heap_table_size的值应该保持一致，以避免意外行为。

键缓冲区大小

如果你还在使用MyISAM表（虽然WordPress主要使用InnoDB，但有些插件可能还会创建MyISAM表），那么需要设置：

key_buffer_size=200M

对于大量使用MyISAM的情况，可以考虑增加key-cache-segments到4或8。

线程与连接优化

网站并发访问量大的时候，线程和连接管理就显得尤为重要。每个MySQL连接都会消耗一定的资源，因此需要合理配置。

最大连接数

默认的max_connections=151可能不够用，特别是当你有多个网站同时运行，并且使用了缓存插件的情况下：

max_connections=300

但这需要根据你的实际并发连接数进行调整，不建议设置过高，否则可能导致内存耗尽。

线程池配置

对于短查询为主的OLTP工作负载（如WordPress），线程池可以显著提高性能。启用方法如下：

thread-handling=pool-of-threads

这在高并发场景下可以避免频繁创建和销毁线程的开销，大幅提升性能。

InnoDB专项调优

InnoDB是MariaDB默认的存储引擎，也是WordPress所有表使用的引擎，因此针对InnoDB的优化尤为重要。

日志刷写策略

InnoDB的日志刷写策略对性能影响极大。默认设置（innodb_flush_log_at_trx_commit=1）保证数据安全，但会影响性能。对于非金融级的应用，可以适当调整以提升性能：

innodb_flush_log_at_trx_commit=2

如果你的数据安全性要求不是极高，甚至可以设置为0，这可以显著提升MariaDB的运行速度。

并发线程控制

innodb_thread_concurrency=20

这个值建议设置为CPU核心数的10倍左右。对于我们2核的服务器，20是一个合理的值。

其他InnoDB优化

innodb_lock_wait_timeout=300
innodb_file_per_table=1

innodb_file_per_table=1确保每个表有独立的表空间，便于管理和优化。

查询优化器配置

MariaDB 10.6的查询优化器有了不少改进，但需要正确配置才能发挥最大效果。

优化器开关

WordPress的某些查询（特别是涉及meta_query的复杂查询）可能性能较差。通过调整优化器开关，可以改善这种情况：

optimizer_switch='join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on'

要检查这些优化器附加组件是否已启用，可以在MariaDB客户端执行：

SELECT @@optimizer_switch;

确保输出中包含join_cache_incremental=on、join_cache_hashed=on和join_cache_bka=on。

优化器搜索深度

对于复杂的WordPress查询，调整优化器搜索深度也能带来性能提升：

optimizer_prune_level=0
optimizer_search_depth=8

这些设置特别适用于MariaDB 10.6，可以帮助优化器找到更有效的查询计划。

WordPress特定优化

WordPress的数据库查询模式有其特殊性，因此需要一些针对性的优化。

解决SQL_CALC_FOUND_ROWS性能问题

如果你在慢查询日志中看到包含SQL_CALC_FOUND_ROWS的查询，这通常是WordPress分页查询引起的性能问题。解决方案有两种：

1. 通过WordPress查询参数禁用found_rows：

$query = new WP_Query([
    'no_found_rows' => true,
    // ...其他参数
]);

2. 如果无法修改代码，可以考虑通过索引优化这类查询，特别是确保wp_posts表上的post_type、post_status和post_date字段有合适的索引。

表缓存优化

WordPress会频繁打开多个表，因此需要适当增加表缓存：

table_open_cache=60000
table_open_cache_instances=4
table_definition_cache=60000

这些设置对于有大量插件和主题的WordPress站点尤为重要。

监控与维护

优化不是一劳永逸的，需要定期监控和维护。

慢查询日志

启用慢查询日志可以帮助你发现性能瓶颈：

slow_query_log=1
slow_query_log_file=/var/log/mariadb/slow.log
long_query_time=2

定期分析慢查询日志，找出需要优化的查询。

定期维护

每周对频繁更新的表执行优化操作：

OPTIMIZE TABLE wp_posts, wp_postmeta;

这可以帮助整理表碎片，提高查询性能。

总结

MariaDB 10.6在正确配置后，完全可以应对三个日IP 5000的WordPress网站的运行需求。关键是要根据服务器资源合理分配内存，针对WordPress的查询模式优化配置，并定期监控性能。

通过以上优化，我的WordPress站点从之前的秒开还经常卡顿，到现在即使在高并发情况下也能快速响应。记住，数据库优化是一个持续的过程，需要根据实际运行情况不断调整。