内容摘要：dedeCMS织梦）的数据库表结构，说好听点叫“灵活”，说难听点叫“散装”。官方文档写得云山雾绕，但真正动起手来，你只需要记住几个核心表，剩下的全是围绕它们打转的附属品。 先看最核心的 dede_ar

dedeCMS（织梦）的数据释数据库表结构，说好听点叫“灵活”，库表说难听点叫“散装”。及字官方文档写得云山雾绕，段名但真正动起手来，称解你只需要记住几个核心表，数据释剩下的库表全是围绕它们打转的附属品。

先看最核心的及字 dede_archives——这张表存的是所有文档的“公共属性”。id、段名标题、称解发布时间、数据释点击量、库表所属栏目id，及字全在这。段名注意，称解它不存正文内容。正文在哪？在分表里。dede_addonarticle 是文章模型的附加表，存正文、摘要、关键词；dede_addonsoft 是软件模型，存下载地址、文件大小、版本号。你建了几个内容模型，就有几张对应的 dede_addon* 表。这种“主表+附加表”的设计，当初是为了让不同模型共享同一套发布时间、点击统计逻辑，但代价就是联表查询时你得写清楚关联条件，否则数据会翻倍。

栏目表 dede_arctype 得单独拎出来说。它有个字段叫 reid，存的是父级栏目id。织梦的栏目层级就靠这个字段递归实现。但坑在于，reid 默认是0，代表顶级栏目，如果你删了父栏目，子栏目的 reid 不会自动更新，得手动改，不然后台栏目树就乱了。还有个 typedir 字段，存的是栏目的目录路径，比如 /news/，但注意，它存的是相对路径，不包含域名，生成静态页时织梦会自己拼上站点根地址。

字段命名上，织梦有个“坏习惯”——喜欢用拼音缩写。litpic 是缩略图，writer 是作者，source 是来源。这些还好猜，但 mid 是会员id，arcrank 是文档阅读权限等级（0是公开，-1是待审核），money 是收费文档的积分价格，这几个就有点考验悟性了。我第一次查 arcrank 时，愣是没搞明白为什么有负数，后来翻后台源码才发现 -1 代表“未审核”，-2 是“拒绝”，只有0以上才是正常公开状态。

再说说 dede_member 和 dede_member_type。前者是前端注册用户表，存用户名、密码（md5加盐）、积分。后者是会员等级表，对应后台“会员模型”里的等级设置。这里有个容易踩的坑：dede_member 里的 mtype 字段，默认是0，代表普通注册用户，但如果你开了付费会员功能，这个字段会存 dede_member_type 里的 rank 值。等级不同，能看的文档权限就不同——这跟 arcrank 是两套独立体系，一个是文档侧限制，一个是用户侧限制，别搞混。

最后提醒一句，织梦的 dede_uploads 表是存附件信息的，但图片路径 url 字段只存相对路径，比如 /uploads/allimg/230101/1-2301011A426.jpg。如果你迁移网站，得先把这表里的路径批量替换成新域名，否则图片全挂。别问我是怎么知道的——我帮人修过三次搬家后图片丢失的站，全是这毛病。

记住，织梦的表结构不是为性能极致优化设计的，而是为“后台操作直观”设计的。你要改数据，优先改 dede_archives 和对应模型附加表，别碰 dede_arctype 的 reid 除非你清楚自己在干嘛。字段名看不懂时，拿个SQL工具连上去，对着后台界面点几下，看哪个数据变了，就明白那个字段是干嘛的了。这法子比查任何文档都管用。