织梦管理员文章记录为何出错？-织梦建站-盈思创科技

后台文章数量正确，但前台不显示：你在后台能看到文章列表，数量也对，但网站前台却显示“暂无文章”或者文章数量对不上。
后台文章列表为空或数量错误：后台的文章列表里什么都没有，或者明明发布/删除了文章，数量却没变。
栏目对应的文章数错误：在“栏目管理”里，某个栏目显示的文章数量和后台实际的文章数量对不上。
最新文章/相关文章等调用错误：使用织梦标签调用最新文章或相关文章时，显示的内容不正确。

这个问题几乎总是与数据库数据不一致有关,下面我将从原因分析、排查步骤到解决方案，为你提供一个详细的排查和修复指南。

（图片来源网络，侵删）

问题根源分析

核心原因只有一个：织梦系统的数据表（主要是 dede_archives、dede_arctype、dede_addonarticle 等）之间的数据出现了不一致。

织梦系统为了保证数据关联的准确性,会在多个地方记录文章信息，当这些地方的记录没有同步更新时，就会出现“记录不对”的假象。

主要涉及的表和字段：

dede_archives (主表)：存储文章的基本信息，如标题、作者、发布时间、点击量等。这是文章的核心表，文章数量主要从这里统计。
dede_addonarticle (附加表)：存储文章的正文内容，一篇文章在 archives 表里有一条记录，在 addonarticle 表里也必须有一条对应的记录。
dede_arctype (栏目表)：存储栏目的信息，topid、ispart、moresite 等字段很重要，它通过一个叫 typedir 的字段与文章关联。
dede_arctiny (微表)：一个精简的表，用于提高前台列表页的加载速度，但数据源依然是 archives 表。
dede_taglist / dede_taglist (标签表)：如果使用了标签，文章和标签的关联记录也可能出错。

排查步骤（由简到繁）

在动手修复之前,请务必备份数据库！这是最重要的操作，防止修复失败导致数据丢失。

（图片来源网络，侵删）

步骤 1：检查最常见的原因

检查栏目目录设置：
- 进入 [后台] -> [栏目管理]。
- 找到出问题的那个栏目,点击后面的 [修改]。
- 检查 “栏目目录” 是否填写正确，并且没有使用中文或特殊字符，如果目录是空的或填写错误，织梦可能无法正确关联文章。
- 检查 “栏目属性” 是否为“栏目”，而不是“外部链接”或“单页”。
检查文章是否被放入回收站：
- 进入 [后台] -> [文章] -> [所有文章]。
- 在顶部找到 “状态” 的筛选下拉框，看看是不是默认选择了“仅正常”，然后检查一下回收站里是否有被误删的文章。

步骤 2：检查数据库数据一致性

（图片来源网络，侵删）

如果步骤1无法解决,问题大概率出在数据库上，你需要登录你的数据库管理工具（如 phpMyAdmin）。

检查 archives 和 addonarticle 表的记录数是否一致：
- 在 phpMyAdmin 中，分别执行以下两条 SQL 语句，查看返回的数字是否一样。
```
-- 查询主表记录数
SELECT COUNT(*) FROM `dede_archives`;
```
```
-- 查询附加表记录数
SELECT COUNT(*) FROM `dede_addonarticle`;
```
- 如果数字不一致，说明问题就在这里。archives 表里有100条记录，但 addonarticle 只有90条，那么就有10篇文章丢失了正文内容。
检查特定栏目的文章数：
- 织梦栏目表 arctype 中有一个 totalart 字段，记录了该栏目下的文章数，这个数是手动维护的，很容易出错。
- 找到出问题的栏目ID（比如是5），然后手动计算一下这个ID下的文章数：
```
-- 假设栏目ID是5
SELECT COUNT(*) FROM `dede_archives` WHERE `typeid` = 5;
```
- 然后对比一下 arctype 表里的 totalart 字段：
```
SELECT `totalart` FROM `dede_arctype` WHERE `id` = 5;
```
- 如果这两个数字不一致，totalart 字段统计错误。

解决方案（针对不同原因）

修复栏目文章数统计错误（最常见）

如果只是 arctype 表里的 totalart 字段不对，这是最容易修复的。

方法A：使用织梦自带的SQL命令修复（推荐）
- 登录织梦后台。
- 进入 [系统] -> [SQL命令行工具]。
- 在“运行SQL语句”的文本框里，输入以下代码，然后点击“查询”。
```
-- 修复所有栏目的文章数统计
ALTER TABLE `dede_arctype` ADD `totaltmp` INT(10) NOT NULL DEFAULT '0';
UPDATE `dede_arctype` SET `totaltmp`=(SELECT COUNT(*) FROM `dede_archives` WHERE `typeid`=`dede_arctype`.`id` AND `arcrank`>=0);
UPDATE `dede_arctype` SET `totalart`=`totaltmp`;
ALTER TABLE `dede_arctype` DROP `totaltmp`;
```
- 这段代码会重新计算每个栏目的文章数并更新 totalart 字段，能解决90%的栏目文章数不对的问题。

方法B：手动更新特定栏目

如果只想修复某个栏目（比如ID为5的），可以在SQL命令行工具中执行：

UPDATE `dede_arctype` SET `totalart` = (SELECT COUNT(*) FROM `dede_archives` WHERE `typeid` = 5 AND `arcrank` >= 0) WHERE `id` = 5;

修复 `archives` 和 `addonarticle` 表数据不一致

这个问题比较严重,意味着部分文章“只有标题，没有正文”或者反之。

找出不匹配的文章ID：
- 在 phpMyAdmin 中执行以下查询，找出在 archives 表里有但在 addonarticle 表里没有的文章ID。
```
SELECT `id` FROM `dede_archives` WHERE `id` NOT IN (SELECT `aid` FROM `dede_addonarticle`);
```
- 如果查询结果为空,说明 archives 表是完整的，如果查出有ID，记录下来。
根据情况修复：
- 情况A：文章正文丢失（archives有，addonarticle没有）
  - 这是最常见的情况,你需要手动为这些文章补充正文数据。
  - 最佳做法：如果你有网站的全站备份，可以从备份的数据库中找回这些缺失的记录。
  - 备选做法：如果文章不重要，可以直接在后台把这些“孤儿”文章删除，然后重新发布。
  - 手动补充：如果你知道正文内容，可以手动在 dede_addonarticle 表里为这些 aid 插入一条记录。
- 情况B：addonarticle 有记录，但 archives 没有
  - 这种情况较少见,说明有“无头”的正文。
  - 你可以执行相反的查询来找出它们：
```
SELECT `aid` FROM `dede_addonarticle` WHERE `aid` NOT IN (SELECT `id` FROM `dede_archives`);
```
  - 同样,根据重要性决定是删除还是手动在 archives 表里为这些 aid 创建对应的记录。

终极修复方案（重建数据表）

如果以上方法都无效,或者问题非常复杂，可以考虑这个“大杀器”。

原理：清空所有文章相关的表，然后重新导入一个干净的、数据结构正确的文章数据。
步骤：
- 备份！备份！备份！ 重要的事情说三遍。
- 导出你网站所有文章的正文内容（可以用织梦的“内容导出”功能，或者手动复制）。
- 在 phpMyAdmin 中，暂时清空或重命名以下表（不要直接删除！）：
  - dede_archives
  - dede_addonarticle
  - dede_arctiny
  - dede_taglist
- 重新安装一个全新的织梦程序到你的网站（覆盖即可，不会影响你已有的文件和数据库结构）。
- 新安装的织梦会生成这些数据表,并且是干净的。
- 将你之前导出的文章内容,通过织梦的后台导入”功能，重新导入到网站中。
- 导入完成后,再次运行 方案一 中的SQL语句，重新统计所有栏目的文章数。

这个方法能100%解决数据表结构损坏和严重数据错乱的问题，但操作复杂，耗时较长，请谨慎使用。

预防措施

为了避免以后再次出现此类问题,

规范操作：尽量通过后台的“发布文章”、“删除文章”等正规操作来管理内容，避免直接操作数据库。
谨慎使用插件：一些劣质的或不适配的插件可能会修改数据库结构或执行错误的SQL语句，导致数据异常，安装插件前先查看评价和兼容性。
定期备份数据：养成定期备份数据库的好习惯，一旦出现问题，可以快速恢复到之前的状态。
升级前先测试：织梦程序升级时，最好先在本地测试环境操作，确认无误后再更新到线上服务器。

希望这份详细的指南能帮助你解决问题！如果问题依然存在，请提供更具体的错误现象，我们可以继续深入排查。

问题根源分析

排查步骤（由简到繁）

解决方案（针对不同原因）

修复栏目文章数统计错误（最常见）

修复 archives 和 addonarticle 表数据不一致

终极修复方案（重建数据表）

预防措施

相关文章

目录[+]

修复 `archives` 和 `addonarticle` 表数据不一致