ZBlogCMS 数据库损坏该如何修复

学完这篇，你能自己定位 ZBlogCMS（ZBlogPHP）的数据库报错属于哪一类损坏，并按「备份 → 检测 → 修复 → 恢复」的顺序把站点救回来，不必一上来就重装。

第一步：先确认到底是不是数据库坏了

这一步要拿到明确的错误信息，避免白折腾。ZBlogPHP 出错时页面会显示红色错误提示，或者后台直接白屏。常见的数据库类报错有三种：

• Table 'zbp_xxx' is marked as crashed and should be repaired——MySQL 表崩溃，最好修。
• MySQL server has gone away 或 Lost connection during query——多半是单表损坏，或 max_allowed_packet 太小。
• 后台能登录但文章列表空白、评论 500——可能是 zbp_config、zbp_post 这类核心表读不出来。

同时确认你用的是哪种数据库：打开 zb_users/c.php，看 define('ZBP_DATABASE', 'mysql'); 还是 'sqlite'。这两条路的修法完全不同，别搞混。

注意：报错里出现的表名默认带 zbp_ 前缀，如果你安装时改过前缀，以报错里的实际名称为准。

第二步：动手前先做一份完整备份

这一步要拿到可回退的副本，因为修复操作本身可能让情况更糟。

文件层面：把整个网站目录打包下载，至少保下 zb_users/ 和 zb_users/c.php。

数据库层面，MySQL 用命令行导出：

mysqldump -uroot -p --default-character-set=utf8mb4 --single-transaction 数据库名 > zblog_backup.sql

SQLite 版本直接复制数据库文件（默认路径 zb_users/data/sqlite.db）：

cp zb_users/data/sqlite.db zb_users/data/sqlite.db.bak

ZBlogPHP 后台也自带备份入口：登录后台 → 左侧菜单「数据备份」，选择全部表导出。但这招只在后台还能正常打开时可用，坏了就老老实实用命令行。

注意：备份文件名别放在网站根目录下，否则等于把数据库明文暴露在公网。

第三步：MySQL 表级修复

这一步要把「标记为崩溃」的表修回可读状态，多数情况到这一步就结束了。

图形界面走 phpMyAdmin：登录 → 左侧点选你的数据库 → 顶部「结构」标签 → 页面底部「全选」→ 右侧下拉框选「修复表」→ 点「执行」。执行完下拉框再选一次「检查表」，状态显示 OK 即修复成功。

命令行更直接：

mysqlcheck -uroot -p --auto-repair --databases 数据库名

只修某一张表：

mysql -uroot -p 数据库名 -e "REPAIR TABLE zbp_post; CHECK TABLE zbp_post;"

如果是 MySQL server has gone away，顺手把参数调大：在 my.ini（Windows）或 /etc/my.cnf（Linux）的 [mysqld] 段加一行 max_allowed_packet = 64M，重启 MySQL 服务。

注意：REPAIR TABLE 只对 MyISAM 表完全有效。ZBlogPHP 默认建的是 MyISAM 表，如果你建站时手动改成了 InnoDB，命令会报「存储引擎不支持修复」，请看下一步。

第四步：InnoDB 表严重损坏的处理

这一步用于表彻底打不开、连 SELECT 都报错的情况，目标是把数据抢救出来重建。

先改配置：找到 my.cnf 的 [mysqld] 段，加上 innodb_force_recovery = 1，重启 MySQL。还起不来就把数字依次改成 2、3、4，最高试到 6。数据库能启动后，立刻用 mysqldump 把全部数据导出来，然后删掉这行配置、重启 MySQL，再把 SQL 文件导回去。

注意：innodb_force_recovery 大于 0 时数据库是只读的，只能导出不能写入，所以这一步要一口气做完再改回来。

第五步：SQLite 版本的修复

这一步针对单文件数据库。先自检：

sqlite3 zb_users/data/sqlite.db "PRAGMA integrity_check;"

返回 ok 说明文件没坏，问题在别处；返回一串错误行，说明确实损坏。

修复先试最轻的：

sqlite3 zb_users/data/sqlite.db "VACUUM;"

无效就导出重建（需要 SQLite 3.29 以上）：

sqlite3 zb_users/data/sqlite.db .recover > dump.sql
sqlite3 zb_users/data/new.db < dump.sql

然后把 new.db 改名为原文件名，覆盖回 zb_users/data/。如果后台里配过自定义路径，以 c.php 中 ZBP_SQLITE_DATABASE 的值为准。

第六步：表丢失或结构错乱时的恢复

这一步用备份把数据灌回去。MySQL 执行：

mysql -uroot -p --default-character-set=utf8mb4 数据库名 < zblog_backup.sql

导入前建议先新建一个空库测试一遍，确认 SQL 文件本身没损坏。

如果只是某张表丢了，而你手上没有整库备份，可以重新跑一次 ZBlogPHP 安装程序建出完整表结构，再把旧库里能读出来的数据往新表里导——但 zbp_config 这张配置表必须用你自己的旧数据，否则主题、插件、站点地址全都会回到默认值。

第七步：修完后的收尾检查

这一步确认站点真的活了。回到网站根目录，删掉 zb_users/cache/ 下的缓存文件，然后依次验证：首页能打开、后台能登录、文章详情页能打开、评论能提交、插件列表能正常显示。

如果数据库修好了但页面仍然异常，去后台「插件管理」把所有插件停用一轮——插件写坏数据库是常见诱因，而不是数据库自己坏了。

注意：修复完成后立刻再备份一次，并确认 MySQL 用户的 INSERT／UPDATE 权限正常，权限不足会让站点看起来「修好了但发不了文章」。

小结

• 先看报错定位类型，再打开 zb_users/c.php 确认是 MySQL 还是 SQLite。
• 任何修复动作之前，文件和数据库都要先备份，备份别放网站目录。
• MyISAM 表崩溃用 REPAIR TABLE 或 phpMyAdmin「结构 → 全选 → 修复表」；InnoDB 用 innodb_force_recovery 抢救数据后重建。
• SQLite 先 PRAGMA integrity_check，再 VACUUM，最后 .recover 导出重建。
• 表丢失时重装建结构，但 zbp_config 必须保留旧数据。
• 修完删 zb_users/cache/ 缓存，并逐项验证首页、后台、文章页、评论、插件。