首先，咱们先聚焦到你遇到的那条慢查询上——这条语句的性能瓶颈其实不在服务器硬件或MySQL全局配置，而是缺少合适的索引。先解决这个问题，能立竿见影提升查询速度：

1. 给wp_posts表添加针对性索引 #

你的查询语句是：

SELECT DISTINCT YEAR( post_date ) AS year, MONTH( post_date ) AS month FROM wp_posts WHERE post_type = 'attachment' ORDER BY post_date DESC

它的过滤条件是post_type = 'attachment'，同时需要基于post_date做排序和日期提取。建议创建复合覆盖索引：

CREATE INDEX idx_posttype_postdate ON wp_posts (post_type, post_date);

这个索引会让MySQL直接从索引中获取所需数据（无需回表查询原数据），同时利用索引的有序性避免额外排序操作，能把这条查询的执行时间降到毫秒级。

2. 修正my.cnf中的不合理配置 #

你的配置里有几个明显的错误和过度配置，这反而会影响MySQL性能：

（1）会话级缓冲区参数过大 #

以下参数是每个数据库连接都会分配的内存，你设置的数值远超合理范围，会导致内存浪费甚至OOM风险：

• innodb_sort_buffer_size = 180000M：这个值离谱了，正常设置为1M或2M即可（排序操作很少需要这么大的缓冲区）
• join_buffer_size = 96M：建议改为2M-8M
• read_buffer_size = 96M：建议改为1M-4M
• read_rnd_buffer_size = 96M：建议改为4M-8M
• sort_buffer_size = 96M：建议改为2M-4M

（2）适配MySQL版本的参数调整 #

如果你的MySQL版本是8.0+，请删除以下MyISAM相关的查询缓存参数（MySQL8.0已彻底移除查询缓存功能，保留会报错）：

#query_cache_limit = 4M
#query_cache_size = 64M
#query_cache_type = 1

（3）慢查询日志配置优化 #

为了更方便排查后续慢查询，建议调整：

long_query_time = 0.1  # 把慢查询阈值从5秒降到0.1秒，捕捉更多潜在慢查询
slow_query_log = 1     # 开启慢查询日志，生产环境只要磁盘足够就建议开启

（4）其他合理调整建议 #

• innodb_thread_concurrency = 0：保持默认0即可，MySQL会自动适配CPU核心数
• max_connections = 10000：这个值过大，256G内存的服务器设置1000-2000足够，过多连接会占用大量内存

3. WordPress层面的额外优化 #

除了MySQL配置，你还可以通过WordPress插件减少数据库查询压力：

• 启用对象缓存：比如用Redis或Memcached缓存数据库查询结果，避免重复执行相同查询
• 检查WordPress缓存插件：确保页面缓存正常工作，未缓存的页面尽量通过缓存层减少数据库访问

验证效果 #

完成上述调整后，重启MySQL服务，再用Query Monitor查看那条慢查询的执行时间，应该会有明显下降。同时持续观察服务器负载，确保内存和CPU使用处于合理范围。

内容的提问来源于stack exchange，提问作者Matei Zoc