织梦DedeCMS批量清空数据并ID归零的SQL命令实战整理

保哥做企业站点交付，最常遇到的一个收尾环节就是：测试期间填充了一堆假数据、栏目和文章被反复增删，到了正式上线那一刻，客户希望整个后台是干净的，文章ID从1开始、栏目编号也从1开始。如果只是从后台一条条删，效率低不说，自增ID依然不会归零，看起来非常不专业。这篇文章把我多年实操织梦DedeCMS（包括早期的5.7 SP2和后来的若干修复版）总结的批量清空SQL命令整理一遍，并把每条语句背后的原理、风险点、踩坑经验全部写清楚，方便后来者照单全收。

一、为什么要用SQL命令而不是后台逐条删除

刚接触织梦的朋友可能会问，后台不是有「批量删除文档」「批量删除栏目」吗，为什么还要绕一圈写SQL？保哥早期也是这么干的，结果发现几个非常麻烦的问题。

第一，后台批量删除受单页条数限制。如果你测试阶段灌了几千条文章，光是翻页删除就要花掉一两个小时，而且中途网络一断就要重来。第二，最关键的一点：后台删除并不会重置自增ID。比如你删了500篇文章，再发一篇新文章，它的aid会从501开始而不是1。对于追求URL美观、对aid有规划的SEO项目来说，这是不可接受的。第三，织梦的文章数据不是单表存储，它至少分布在dede_archives、dede_addonarticle、dede_arctiny三张表中，后台删除偶尔会出现孤立数据，导致后台列表正常但前台模板渲染报错。

所以保哥的标准做法是：直接进入织梦后台的SQL命令行工具（路径在「系统 → 系统设置 → SQL命令行工具」），勾选「多行命令」，把下面分类整理好的语句复制粘贴执行，几秒钟就能完成所有清理。

二、清空所有栏目（dede_arctype）

栏目表是织梦内容结构的骨架，所有文章都挂在栏目下，一旦栏目被清掉，文章列表也会出现「未指定栏目」的提示。所以如果你只是想重置文章而保留栏目，不要执行这一段。

Delete from dede_arctype;
ALTER TABLE dede_arctype AUTO_INCREMENT = 1;

第一行把dede_arctype表里的所有记录干掉，第二行把这张表的自增ID重置为1，下次新建第一个栏目，它的id就是1。这里保哥特别提醒一句：织梦的栏目支持嵌套，子栏目通过reid字段指向父栏目id，所以一旦清空就是连根拔起，不存在「只删某一个分类下所有子栏目」这种半截操作。

如果只想删除某一个父栏目下的全部子栏目，可以用条件式删除：

Delete from dede_arctype WHERE reid = 5;

这条语句会把reid=5的所有子栏目删掉，但不影响id=5本身和其他不相关栏目。

三、清空所有文章（三张表必须一起处理）

这是保哥踩坑最多的地方。织梦的「一篇文章」其实是三张表配合写入的：

• dede_archives：文档主表，存标题、栏目、发布时间、点击数等核心字段；
• dede_addonarticle：附加表，存正文body字段（普通文章模型）；
• dede_arctiny：极简索引表，存最简文档信息，主要给URL路由用。

如果只删了dede_archives而忘了dede_addonarticle，会出现「文章已删除但正文仍在数据库占用空间」的状况，长期累计会让数据库膨胀；如果只删了dede_archives而忘了dede_arctiny，前台访问旧URL会出现路由异常。所以一定要三张表一起来：

Delete from dede_addonarticle;
ALTER TABLE dede_addonarticle AUTO_INCREMENT = 1;
Delete from dede_arctiny;
ALTER TABLE dede_arctiny AUTO_INCREMENT = 1;
Delete from dede_archives;
ALTER TABLE dede_archives AUTO_INCREMENT = 1;

顺序上保哥习惯是先删附加表、再删极简索引、最后删主表。原因是从依赖关系上讲，dede_addonarticle和dede_arctiny是依赖dede_archives.aid存在的，先删依赖方再删被依赖方，逻辑上更干净，虽然在MySQL层面上由于织梦没有用外键约束，顺序对结果没有强制影响。

如果你的站点开了图集、软件下载等其他文档模型，还要补上对应的附加表，比如：

Delete from dede_addonimages;
ALTER TABLE dede_addonimages AUTO_INCREMENT = 1;
Delete from dede_addonsoft;
ALTER TABLE dede_addonsoft AUTO_INCREMENT = 1;

这两张表分别对应图集模型和软件下载模型，没用到的可以跳过。

四、清空文档关键词与搜索关键词

织梦有两套关键词机制，新手很容易混淆，保哥这里掰开讲清楚。

第一套是文档关键词，存在dede_keywords表里，用于「关键词维护」功能（早期可以做关键词替换内链，但因为容易被搜索引擎判定为黑帽内链，新版本已经默认关闭）。

Delete from dede_keywords;
ALTER TABLE dede_keywords AUTO_INCREMENT = 1;

第二套是搜索关键词，存在dede_search_keywords表里，用于记录用户在前台搜索框中输入过的词，便于后台统计热门搜索。

Delete from dede_search_keywords;
ALTER TABLE dede_search_keywords AUTO_INCREMENT = 1;

两张表互不干扰，都建议在交付前清空，避免把测试阶段乱搜的「测试」「123」之类的词留给客户看到。

五、清空标签系统（dede_tagindex 与 dede_taglist）

标签也是两张表配合的，dede_tagindex存标签本身（tag名、点击数、is_hot等），dede_taglist存「这个标签下有哪些文章」的对应关系。两张表必须一起清，否则会出现「标签已经不存在但文章列表里还显示该标签」的诡异情况。

Delete from dede_tagindex;
ALTER TABLE dede_tagindex AUTO_INCREMENT = 1;
Delete from dede_taglist;
ALTER TABLE dede_taglist AUTO_INCREMENT = 1;

清完之后，原先在文章发布页填过的TAG也会一并消失，下次发新文章时重新填即可。

六、清空上传目录中的图片与附件

SQL语句只能处理数据库，处理不了文件系统。织梦后台上传的图片、附件物理文件存放在站点根目录的uploads文件夹下，以年月命名子目录，例如uploads/allimg/191110/、uploads/soft/191111/这样的结构。

保哥推荐两种清理方式：

方式一：图形化删除。 用FTP工具（FileZilla、WinSCP）连接服务器，进入uploads目录，把所有日期格式的子文件夹（如allimg下面的191110、191111...）选中删除。注意uploads本身不要删，它是织梦默认的上传根目录，删掉之后再上传图片会报路径错误。

方式二：命令行删除。 如果你有SSH权限，进入站点根目录后执行：

cd uploads/allimg && rm -rf 19* 20* 21*

这条命令会删掉以19、20、21开头的所有子目录（覆盖2019到2199年的可能命名），干净利落。删完之后建议再看一眼uploads/userup、uploads/soft、uploads/media这几个常用子目录，按需清理。

执行完文件清理后，记得回到织梦后台「核心 → 附件管理」里再点一下「不存在文件检测」，把数据库里残留的附件记录也一并清理，避免数据不一致。

七、保哥的完整清空流程SOP

为了方便后续交付项目时直接照搬，保哥把上面所有步骤打包成一个标准操作流程：

第一步，做完整数据库备份。后台「系统 → 数据库备份/还原」一键全选备份，或者用phpMyAdmin/Navicat导出整个数据库，文件保留至少一份。这一步绝对不能省，SQL语句一旦执行不可逆。

第二步，关闭前台访问。在系统设置里把站点改为「关闭」状态，避免清理过程中有用户访问触发奇怪报错。

第三步，按上面顺序依次执行SQL：先清栏目（如有需要）、再清三张文章表、再清关键词与搜索词、最后清标签。所有语句可以一次性粘进多行命令框里执行。

第四步，清空uploads物理文件，参考第六节。

第五步，更新缓存与索引。回到后台执行「生成 → 更新主页」「生成 → 更新栏目」「生成 → 更新文档HTML」三个动作，把残留的静态HTML一并刷新。再去「核心 → 批量维护 → 文档重新审核」里走一遍，确保没有孤立索引。

第六步，重启站点，检查首页、列表页、详情页是否正常显示「暂无内容」类提示，没有报错就算交付完成。

八、常见问题与避坑提醒（FAQ）

Q1：执行SQL后提示「Table doesn't exist」是怎么回事？

大多数情况是因为你的织梦版本表前缀不是dede_。早期版本默认前缀就是dede_，但安装时可以自定义。打开站点根目录的data/common.inc.php，找到$cfg_dbprefix这一行，看到的就是你站点的真实前缀，把上面所有SQL中的dede_替换成你的实际前缀即可。

Q2：执行后ID没有归零，仍然从原来最大值往后加，怎么办？

说明你只跑了Delete from却忘了跑ALTER TABLE ... AUTO_INCREMENT = 1。Delete只删除数据行，自增计数器仍然记着上一次的最大值，必须显式重置。如果重置后仍然不归零，请确认表是InnoDB引擎且MySQL版本足够新；早期MyISAM版本的织梦数据库一般没有这个问题。

Q3：清空数据后能否撤销恢复？

不能直接撤销。Delete语句一旦提交事务就完成了，没有Ctrl+Z。唯一的恢复方式是从你之前做的数据库备份里还原。所以保哥反复强调：执行任何批量删除前，先做备份、先做备份、先做备份。

Q4：如果只想清理某一段时间内的测试文章，而不是全部清空，怎么写SQL？

这个比较常见，我也经常这么干。可以加一个时间条件，比如：

Delete from dede_archives WHERE pubdate >= UNIX_TIMESTAMP('2019-11-01') AND pubdate < UNIX_TIMESTAMP('2019-12-01');

但要注意，单删dede_archives不够，对应的dede_addonarticle和dede_arctiny也要按aid一起删。可以先把要删的aid查出来：

SELECT id FROM dede_archives WHERE pubdate >= UNIX_TIMESTAMP('2019-11-01');

然后用DELETE FROM dede_addonarticle WHERE aid IN (...)这种形式逐表删除，比较保险。

九、写在最后

织梦DedeCMS虽然这几年因为安全更新和版权问题逐渐淡出主流视野，但保哥手上仍有不少老客户的存量站点跑在DedeCMS上，运维交接时这套清空SQL几乎每个月都要用一次。把它整理成上面的标准化流程，既是给自己的备忘，也希望能帮到那些接手老站点、需要在交付前还原一个干净后台的同行。所有命令都在保哥本地的5.7 SP2和UTF-8修复版上反复验证过，按步骤执行不会出现意外。如果你的版本是某些第三方修改版（例如带有DedeBIZ商业插件），表结构可能略有差异，记得先在测试环境跑一遍再上正式服务器。