wp db check / wp db optimize — 被忽视的数据库健康检查命令

A WordPress database doesn’t tidy itself up over time. Spam comments pile up, expired transients linger, post revisions accumulate, and tables left behind by uninstalled plugins never quite go away. All of that adds up to bloated tables, and occasionally to actual table corruption. This is territory the admin dashboard barely shows you — but WP-CLI reaches it directly with two short commands: wp db check and wp db optimize. WordPress 数据库不会随着时间的推移自动清理。垃圾评论堆积、过期的瞬态数据（transients）残留、文章修订版本不断累积，以及已卸载插件留下的数据表也从未真正消失。所有这些都会导致数据表臃肿，有时甚至会导致数据表损坏。这是 WordPress 后台管理界面几乎无法触及的领域，但 WP-CLI 可以通过两个简短的命令直接处理：wp db check 和 wp db optimize。

Note: WP-CLI’s wp db subcommands operate directly on the MySQL (or MariaDB) database WordPress uses, without going through the admin dashboard. Connection details are read automatically from wp-config.php. 注意：WP-CLI 的 wp db 子命令直接作用于 WordPress 使用的 MySQL（或 MariaDB）数据库，无需经过后台管理界面。连接信息会自动从 wp-config.php 中读取。

wp db check — verifying table health

wp db check — 验证数据表健康状况

wp db check Under the hood, this runs the equivalent of mysqlcheck --check against every table and reports each one’s status: wp db check 在底层，它相当于对每个数据表运行 mysqlcheck --check，并报告每个表的状态：

wp_posts OK
wp_options OK
wp_postmeta OK

If a table comes back corrupt, SELECT and INSERT queries against it start failing. That can surface as something oddly specific — a single page going blank, one particular post refusing to save — with no obvious connection to a database problem. Running wp db check on a regular schedule catches that kind of issue before it turns into a visible symptom. 如果数据表返回损坏状态，针对该表的 SELECT 和 INSERT 查询就会开始失败。这可能会表现为一些奇怪的特定问题——比如某个页面变白、某篇文章无法保存——而这些问题表面上与数据库故障并无明显关联。定期运行 wp db check 可以在问题演变成可见症状之前将其捕获。

wp db optimize — defragmenting tables

wp db optimize — 数据表碎片整理

wp db optimize This one runs the equivalent of mysqlcheck --optimize, applying OPTIMIZE TABLE to each table. Tables that see a lot of row deletions and updates tend to become fragmented on disk over time. OPTIMIZE TABLE rebuilds the table and reclaims the space that deleted rows used to occupy. wp db optimize 此命令相当于运行 mysqlcheck --optimize，对每个表执行 OPTIMIZE TABLE。经历大量行删除和更新操作的数据表，随着时间的推移往往会在磁盘上产生碎片。OPTIMIZE TABLE 会重建数据表并回收已删除行所占用的空间。

Note: behavior differs by storage engine. WordPress’s default engine, InnoDB, handles OPTIMIZE TABLE internally as a table rebuild (roughly equivalent to ALTER TABLE ... FORCE), which both defragments the table and refreshes its statistics. The older MyISAM engine doesn’t reclaim space from deleted rows automatically at all — that disk space only gets released once OPTIMIZE TABLE runs. Some installs set up through a hosting provider’s one-click installer still carry MyISAM tables left over from an older default, so it’s worth checking for a mixed-engine setup once with wp db query "SHOW TABLE STATUS". 注意：不同存储引擎的行为有所不同。WordPress 的默认引擎 InnoDB 在内部将 OPTIMIZE TABLE 处理为表重建（大致相当于 ALTER TABLE ... FORCE），这既能整理表碎片，又能刷新统计信息。较旧的 MyISAM 引擎则完全不会自动回收已删除行的空间——只有在运行 OPTIMIZE TABLE 后，这些磁盘空间才会被释放。一些通过主机商一键安装程序建立的站点可能仍保留着旧版本默认的 MyISAM 表，因此建议使用 wp db query "SHOW TABLE STATUS" 检查一次是否存在混合引擎配置。

wp db optimize locks each table for writes while it runs. On a large table that can mean a brief slowdown for site visitors, so it’s safer to run during a low-traffic window rather than in the middle of the day. wp db optimize 在运行时会锁定每个表以禁止写入。对于大型数据表，这可能意味着访客会经历短暂的访问延迟，因此在低流量时段运行比在白天高峰期运行更安全。

When to actually run these

何时运行这些命令

Neither command causes harm if run at an arbitrary time, but a few moments make the payoff clearer: 在任何时间运行这些命令都不会造成损害，但在以下几个时刻运行效果更佳：

• Right after a bulk deletion — clearing out spam comments in bulk, deleting a large batch of posts, or uninstalling a plugin that no longer gets used, all shrink row counts suddenly. 批量删除操作后 — 批量清理垃圾评论、删除大量文章或卸载不再使用的插件后，行数会突然减少。
• Before a major update — running wp db check ahead of a large WordPress core or plugin update makes it easier to tell, after the fact, whether a problem was caused by the update or was already sitting in the database beforehand. 重大更新前 — 在进行大型 WordPress 核心或插件更新前运行 wp db check，可以更容易判断更新后出现的问题是由更新引起的，还是数据库本身早已存在的问题。
• As part of routine maintenance — folding these into a weekly or monthly cycle turns fragmentation and corruption from “discovered too late” into something checked on a predictable schedule. 作为日常维护的一部分 — 将其纳入每周或每月的维护周期，可以将碎片化和损坏问题从“发现太晚”转变为“按计划检查”。

If corruption turns up — wp db repair

如果发现损坏 — wp db repair

When wp db check reports a table as corrupt, WP-CLI offers wp db repair (the equivalent of mysqlcheck --repair) as a next step. Repair isn’t guaranteed to restore the data perfectly — depending on how severe the corruption is, some data can still be lost. Taking a fresh backup before attempting a repair is a prerequisite, not an optional step. A backup taken moments before the corruption is worth far more than one taken after the fact. 当 wp db check 报告数据表损坏时，WP-CLI 提供了 wp db repair（相当于 mysqlcheck --repair）作为下一步操作。修复并不保证能完美恢复数据——根据损坏程度的不同，仍可能丢失部分数据。在尝试修复之前进行备份是前提条件，而非可选项。在损坏发生前一刻进行的备份，其价值远高于事后备份。

Summary

总结

What you want to do	Command
Check every table’s health	wp db check
Defragment tables and reclaim disk space	wp db optimize
Attempt to repair a corrupted table	wp db repair (back up first)
Check for mixed storage engines	wp db query "SHOW TABLE STATUS"

你想做什么	命令
检查每个表的健康状况	wp db check
整理表碎片并回收磁盘空间	wp db optimize
尝试修复损坏的表	wp db repair (请先备份)
检查是否存在混合存储引擎	wp db query "SHOW TABLE STATUS"

Both wp db check and wp db optimize are lightweight — they finish in seconds to a few minutes — yet they leave a record of the state of the one part of a WordPress site that’s hardest to see from the dashboard. That’s exactly why it’s worth checking mechanically and on a schedule, rather than relying on symptoms to surface first. WP-CLI’s ability to reach the database directly, without going through the admin dashboard, is the same idea behind safely rewriting serialized data with wp search-replace and recovering from a wp-admin lockout. Checking database health is one more basic operation built on that same foundation. wp db check 和 wp db optimize 都非常轻量——只需几秒到几分钟即可完成——但它们记录了 WordPress 站点中最难从后台管理界面观察到的部分的状态。正因如此，定期进行机械化检查非常有必要，而不是等到出现症状后再处理。WP-CLI 无需经过后台管理界面直接访问数据库的能力，与使用 wp search-replace 安全重写序列化数据以及从 wp-admin 锁定中恢复的理念如出一辙。检查数据库健康状况正是建立在这一基础上的又一项基本操作。