一、先给结论（重点）

不要转回 MyISAM。

wp_posts 从 MyISAM 转为 InnoDB 后体积变大，是正常且预期内的结果，这是为了换取：

• 并发能力
• 查询稳定性
• 不锁表
• 不再把 MySQL CPU 打爆

你现在这个站点结构，InnoDB 是“必须项”，不是可选项。

 

二、为什么体积会“翻倍”（你没做错）

你看到的：

• MyISAM：177 MB
• InnoDB：377 MB

原因主要有 5 个，我逐条给你解释清楚。

1️⃣ InnoDB = 数据 + 索引 + 行版本 + MVCC

InnoDB 表实际包含：

• 数据页（16KB）
• 聚簇索引（Primary Key 即数据）
• 二级索引指针
• Undo log / 行版本信息
• 行级锁结构

而 MyISAM：

• 数据文件（.MYD）
• 索引文件（.MYI）
• 没有事务 / 行版本

👉 InnoDB 本身就“更厚重”

2️⃣ 你加了索引（这是“增肥”的主因）

你现在至少有这些索引：

在 MyISAM 时：

• 索引较小
• 结构简单

在 InnoDB：

• 每个二级索引都包含主键
• 索引体积 ≈ MyISAM 的 1.3–1.8 倍

👉 你这是 用空间换性能，而且是“必须换”。

3️⃣ InnoDB 页对齐 + 碎片未整理

刚从 MyISAM 转过来时：

• 行数据重新排布
• 页填充不满
• 存在空洞

后续可以通过：

回收 10–20% 是正常的。

4️⃣ innodb_file_per_table 开启（好事）

你现在看到的是：

• .ibd 文件真实大小
• 而不是共享表空间里的“假小”

👉 这是好事，不是坏事
因为你以后能单表回收空间。

5️⃣ WordPress 本身就不适合 MyISAM

你现在遇到的问题，正是 MyISAM 的典型死穴：

• 没有行锁
• 聚合查询 = 表级锁
• 并发一来直接拖死

👉 你刚好踩中它的极限场景

 

三、那“数据库快 1GB”到底算不算大？

直接给你一个行业级判断：

1GB 的 WordPress 数据库，在 2025 年属于“中等偏小”

对比现实：

• 图片型站：5–20GB
• 内容站：2–10GB
• 外贸备件站（你这种）：1–3GB 非常正常

你服务器是：

• 3.6GB 内存
• MySQL 5.7
• SSD

👉 1GB 数据库完全没压力

 

四、什么时候才“应该转回 MyISAM”？（你不符合）

只有在以下全部成立时，才考虑 MyISAM：

• 只读站
• 几乎无并发
• 不用事务
• 不跑聚合
• 不用 taxonomy
• 不跑 wp-json
• 不关心锁

👉 WordPress 站点几乎永远不满足

 

五、你现在该做的“正确动作清单”

✅ 1️⃣ 保持 InnoDB（不要再纠结）

这是你这次事故的核心解法之一。

 

✅ 2️⃣ 整理空间（推荐）

通常能回收不少。

✅ 3️⃣ 调整 InnoDB 缓存（非常关键）

你内存 3.6GB，建议：

👉 这是比“表小不小”更重要的性能点。

✅ 4️⃣ 清理 WordPress 垃圾数据（可选）

• revisions
• trashed posts
• wp_actionscheduler_logs
• aioseo cache 表

这些加起来，往往能省几百 MB。

 

六、一句直话总结你现在的状态

你刚刚做的这一步（MyISAM → InnoDB），
不是在“让数据库变大”，而是在“把一个不稳定系统升级为工业级结构”。

如果你现在转回去：

• 表会小
• 问题一定会复发
• 而且下次可能更狠