WordPress 越用越慢，多半是数据库在拖后腿
个人站长用 WordPress 建站，前期往往很流畅，站点跑上一年半载之后，后台点一下都转圈、文章列表半天出不来，第一反应通常是「加内存」或「装缓存插件」。但你有没有想过，问题可能根本不在 PHP 和内存，而在数据库里堆积的那些垃圾数据？WordPress 的数据库会随着时间悄悄膨胀：每次保存文章草稿、每个插件选项、每条文章修订版本、每个被垃圾评论和爬虫留下的记录，都在往几张核心表里塞数据。表越大，查询越慢，越慢越拖累整站。
这篇教程从「看」到「治」讲透 WordPress 数据库优化，覆盖最需要关注的几张表、如何安全地清理、以及怎么给数据库做定期体检。所有命令都给出可直接套用的写法，并用「先备份、后操作」的红线贯穿始终。
第一步：先给数据库做个体检，看清谁在占地方
不了解现状就优化等于瞎治。用 SSH 登录服务器，先连上数据库：
mysql -u wpuser -p wordpress_db进去之后逐条执行下面的语句，看每张表的大小和行数。这条会列出所有表，按数据大小降序排列（MySQL 5.7+ / MariaDB 10.2+ 都支持 information_schema）：
SELECT table_name,
ROUND(data_length/1024/1024, 1) AS data_mb,
ROUND(index_length/1024/1024, 1) AS index_mb,
table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY data_length DESC
LIMIT 15;看完你大概率会发现这几张表名列前茅：wp_posts（文章、页面、修订版本全在这里）、wp_postmeta（每篇文章的元数据，插件的自定义字段都塞这）、wp_options（全站配置，autoload 字段还能拖慢每一次请求）、wp_comments 和 wp_commentmeta（垃圾评论）、wp_term_relationships（分类关系）。其中 wp_postmeta 和 wp_options 是重灾区，因为它们经常被插件无节制写入。
wp_options 的 autoload：最影响性能的隐藏炸弹
wp_options 表里有一列叫 autoload。WordPress 启动时会把所有 autoload = 'yes' 的选项一次性读进内存。很多插件把大体积的配置数据也标成 autoload，导致每次页面请求都要加载几百 KB 甚至几 MB 的选项，直接拖慢所有页面。先看看这块有多大：
SELECT COUNT(*),
ROUND(SUM(LENGTH(option_value))/1024, 1) AS autoload_kb
FROM wp_options
WHERE autoload = 'yes';如果 autoload_kb 超过几百 KB，就该动手了。找出体积最大的那些 autoload 选项：
SELECT option_name,
LENGTH(option_value) AS len
FROM wp_options
WHERE autoload = 'yes'
ORDER BY len DESC
LIMIT 20;看到几个几十上百 KB 的、名字明显属于某个插件的选项，就可以把它们改成不自动加载——注意不要改 WordPress 核心选项（如 siteurl、home、blogname、active_plugins、template 等），改错会导致站点打不开。安全做法是：
UPDATE wp_options SET autoload = 'no'
WHERE option_name = '某个大插件选项名';改完记得重启一下 OPcache 或等缓存刷新。更稳妥的替代方案是安装像「WP-Optimize」或「Database Cleaner」这类工具，它们有专门针对 autoload 的清理界面，会标出哪些选项是安全的。不熟悉 SQL 的站长建议用插件，避免误伤核心选项。
清理文章修订版本与自动草稿
WordPress 默认每次保存文章都留一个修订版本（revision），一篇改了二十次的文章就有二十条历史记录，全存在 wp_posts 里。自动保存（autosave）和草稿也会累积。先看看有多少：
SELECT post_type, COUNT(*)
FROM wp_posts
GROUP BY post_type;如果 revision 那一行的数量远超 post，就说明修订版本失控了。清理之前务必先备份，因为删除是物理删除、不可恢复：
DELETE FROM wp_posts
WHERE post_type = 'revision';清理相关元数据（避免孤儿数据）：
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON pm.post_id = p.ID
WHERE p.ID IS NULL;长期方案是限制修订数量。在 wp-config.php 里加一行：
define('WP_POST_REVISIONS', 5);这样每篇文章最多保留 5 个修订版本，既能回滚又不至于无限膨胀。如果你完全不需要历史版本，可以设为 false。
来路不明的孤儿 postmeta 和 term 关系
卸装插件时常常留下大量孤儿数据：插件删了，它往 wp_postmeta 写的字段还在，但对应的文章已经不存在了。这些孤儿行会被扫描但永远用不上，白占空间还拖慢 JOIN。先统计：
SELECT COUNT(*) FROM wp_postmeta pm
LEFT JOIN wp_posts p ON pm.post_id = p.ID
WHERE p.ID IS NULL;数量可观就清理：
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON pm.post_id = p.ID
WHERE p.ID IS NULL;同理清理孤儿评论（wp_comments 里 comment_post_ID 指向不存在的文章的）和孤儿 term 关系。清理这一类数据是「零风险」的——它们本就访问不到，删掉不会影响任何正常功能。
垃圾评论与评论元数据
开着评论的站，垃圾评论和「待审核」里堆积的机器人留言会撑大 wp_comments。先用 SQL 看一眼各种状态的数量：
SELECT comment_approved, COUNT(*)
FROM wp_comments GROUP BY comment_approved;spam 和 trash 状态的可以放心清：
DELETE FROM wp_comments
WHERE comment_approved IN ('spam', 'trash');清完评论再清孤儿 commentmeta：
DELETE cm FROM wp_commentmeta cm
LEFT JOIN wp_comments c ON cm.comment_id = c.comment_ID
WHERE c.comment_ID IS NULL;预防胜于治疗：装 Akismet 或 Antispam Bee 拦截垃圾评论，并关闭「允许对未审核评论的再评论」，能显著减少堆积。
整理表碎片：OPTIMIZE 不是删数据
大量删除之后，表的物理文件并不会自动缩小——MySQL 把空间标记为空闲但保留着，形成「碎片」。这本身不影响正确性，但会浪费磁盘、轻微影响扫描效率。用 OPTIMIZE TABLE 回整理一遍：
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options,
wp_comments, wp_commentmeta, wp_term_relationships;重要提醒：OPTIMIZE 在 InnoDB 上会重建表并加锁（MySQL 8.0 支持在线部分 DDL 但仍有开销），大表执行时站点会短暂卡顿甚至锁表。务必在低峰期执行，或先 SHOW TABLE STATUS 看 Data_free（碎片大小）判断值不值得做。碎片不大就别折腾了，收益有限。
加索引：让慢查询快起来
有时候表的行数并不多，但查询就是慢，原因常常是缺索引。先打开慢查询日志，找出真正拖慢站点的语句。在 my.cnf 里配置：
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 0重启 MySQL 后跑一段时间，用 mysqldumpslow -s t /var/log/mysql/slow.log 看最耗时的是哪些。对高频且慢的查询，用 EXPLAIN 看它有没有走索引、type 是不是 ALL（全表扫描）。注意：不要盲目给 WordPress 表乱加索引，因为 WP 核心表本身的索引是设计好的，加错索引反而拖慢写入。真正需要加索引的场景通常是某个插件自定义的查询，这种情况优先找插件作者或换插件。
数据库连接的常见坑：别让连接数把 MySQL 拖垮
清理数据只是一方面，另一面是「怎么连数据库」。WordPress 默认每处理一个请求就开一次数据库连接、用完再关掉，看起来没问题，但在并发稍高的时候会产生大量的短连接，每一次建连都要经历 TCP 握手和 MySQL 的认证握手，开销不小。前台有缓存插件的话还行，后台或者没缓存的动态页面多了，连接数很容易打满 max_connections，报出经典的 Too many connections，全站白屏。排查连接现状：
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';
SHOW VARIABLES LIKE 'max_connections';如果 Max_used_connections 常年贴着 max_connections，说明确实吃紧。不要简单粗暴地把 max_connections 调大——每个连接都要占内存，调太大会把内存耗尽反而更糟。正确的思路是减少连接需求：装一个持久连接或对象缓存插件，把查询结果缓存到 Redis，让大部分请求根本不碰数据库。这才是治本。
还有一点容易被忽略：wp-config.php 里的 DB_HOST。很多教程告诉你写 localhost，但如果你在 MySQL 里用的是 localhost 而 PHP 又没配好 socket 路径，可能会走 Unix socket 而绕过 TCP，行为在某些环境下不一致。稳妥起见用 127.0.0.1 明确走 TCP，排除 socket 路径带来的玄学问题。
定期体检：把优化变成例行公事
数据库优化不是一次性动作。建议每个月做一次例行检查：跑一遍上面的表大小查询，看有没有异常增长的表；检查 autoload 总量有没有又涨回去；确认修订版本数量受控。把这些查询写成一个 SQL 脚本放在服务器上，用 cron 每月跑一次并把结果发到你的邮箱，就能在问题恶化前发现苗头。
还要养成两个习惯：一是任何 DELETE 之前先 mysqldump 备份（mysqldump -u wpuser -p wordpress_db > backup_$(date +%F).sql），二是清理操作先在测试库或从库上跑一遍，确认没问题再上生产。数据库清理是没有「撤销」按钮的，谨慎永远不亏。
小结
WordPress 变慢，先别急着加配置，花十分钟看看数据库。按「体检 → 清 autoload → 删修订 → 清孤儿 → 清垃圾评论 → 整理碎片」的顺序走一遍，多数老站都能瘦身一半、速度明显回升。核心原则就两条：动手前必备份，以及只清那些明确无用的数据（孤儿记录、修订版本、spam 评论），别碰核心选项。把体检做成每月例行，你的 WordPress 就能长期保持轻快。