DiscuzX3.5用户发表的主题帖子，这些内容保存在哪里？数据库还是网站文件目录里？

豆包

Discuz! X3.5 帖子主题内容存储位置

核心结论：帖子正文、标题、作者等绝大部分内容存在 MySQL 数据库；附件图片/文件是存磁盘文件目录。

1、主题、帖子文字内容（数据库）

Discuz X3.5 所有发帖文字全部在数据库，不在网站文件里。

核心数据表

1. pre_forum_thread —— 主题表（帖子主题）

   • 存储：主题ID、标题、作者ID、发布时间、浏览数、回复数、板块ID、是否置顶、精华、状态等
   • 不存帖子正文内容，只存主题基础信息。

2. pre_forum_post —— 回帖/帖子内容表（最重要）

   • 主题的第一篇内容（楼主正文）也在这里，first=1 代表是主题首帖。
   • 字段 message：帖子正文（带 Discuz 自定义 BBCode 代码，不是纯HTML）
   • 字段 author、authorid：作者信息

     注意：message 里面是 BBCode，不是网页HTML；页面显示的时候程序会把BBCode解析成HTML。

3. pre_forum_post_tableid：帖子分表索引

   当帖子数量巨大时，Discuz会自动分表：pre_forum_post_0、pre_forum_post_1……，数据分散到多张post分表，不是全部在 pre_forum_post。

⚠️：你在网站后台看不到原始数据库，需要 phpMyAdmin 或者 Navicat 连接MySQL查看。

2、图片、附件、头像（磁盘文件目录，不在数据库）

文字在数据库，上传的图片、附件、视频文件保存在服务器硬盘目录：

1. 附件/帖子上传图片
   ./data/attachment/forum/

   • 帖子上传的图片、压缩包等附件全部在这里；
   • 数据库 pre_forum_attachment 表保存附件记录：文件名、文件路径、对应帖子ID；真实文件在磁盘文件夹。

     如果只备份数据库，不备份这个文件夹，帖子文字还在，但是图片全部裂图无法显示。

2. 用户头像
   ./data/attachment/avatar/

3. 编辑器远程保存图片也会落到 data/attachment/forum

3、其他相关

• 帖子缓存：./data/cache/，这只是缓存文件，删除后程序会重新生成，不是原始帖子数据，原始数据依然来自数据库。
• 不要误以为网页缓存文件就是帖子源数据，删除缓存不会丢帖子。

备份要点（非常实用）

1. 完整备份 DiscuzX3.5 需要两部分
   ① MySQL数据库备份：保存帖子文字、用户账号、板块设置等；
   ② 网站文件备份，重点目录：data/attachment/（附件图片）。

   只备份数据库：帖子文字还在，图片附件全部丢失；
   只备份网站文件：帖子文字、用户账号全部丢失。

简单梳理流程

用户发帖 → PHP接收内容 → 写入MySQL pre_forum_thread（主题）+ pre_forum_post（正文）；上传图片写入磁盘 data/attachment/forum，同时在数据库写入附件记录。访问页面时：程序读取数据库BBCode内容，解析BBCode为HTML，再引用磁盘上的图片输出网页。

豆包

数据库最多可以放多少篇主题？分别对应的配置和性能要求是什么？

Discuz X3.5 主题（tid）数量上限、分表、硬件&MySQL配置

重要区分：

• 主题数 = pre_forum_thread 的记录数（tid，一篇主题）
• 帖子总数 = pre_forum_post（pid，楼主+所有回复），数量远大于主题数
  MySQL InnoDB本身没有硬性记录数上限；真正瓶颈是：单表索引大小、IO、内存、Discuz程序分表机制、并发访问。
  X3.5支持主题存档分表（thread分表）、帖子post分表两套独立分表功能。

注意：pre_forum_thread 存主题元数据（标题、fid、浏览数），不存正文；正文在post表。

一、不开启分表（全部数据在单表 pre_forum_thread）

主题数量	状态表现	推荐服务器（Web+DB同机）	MySQL关键配置	备注
0‑30万主题	流畅，绝大多数个人/小站	2核4G，SSD 80G	innodb_buffer_pool_size=2G；开启独立表空间	虚拟主机也能跑，访问量不大即可
30‑80万主题	开始变慢，版块列表、搜索、后台统计卡顿	4核8G，SSD 150G	buffer_pool=5‑6G；优化索引；关闭不必要插件	不建议继续单表跑超过80万主题，列表翻页、后台统计压力陡增
80万‑120万主题	明显卡顿，打开版块慢，后台统计超时	建议Web数据库分离，数据库独立实例：8核16G SSD	buffer_pool=10‑12G；定期optimize表；少用后台批量统计	不开启分表不建议超过120万主题，再往上索引体积巨大，查询性能雪崩

单表硬限制不是MySQL，是Discuz业务SQL：版块列表、筛选、统计、搜索大量扫描pre_forum_thread，记录越多越慢。

二、开启【主题存档分表】（后台：站长‑帖子分表）

Discuz X3.5原生主题分表逻辑：

• 1张主表 pre_forum_thread：存放新主题，允许回复编辑
• N张存档表 pre_forum_thread_0、thread_1 …：旧主题移入存档；存档主题只能浏览，不能回复编辑。

  存档表数量理论无上限；但存档内帖子不能回复，适合归档老历史内容。

分表后规模参考

1. 主表维持50‑80万以内主题，老主题持续移入存档表
2. 总主题（主表+全部存档）可以做到300万‑500万主题。

   ⚠️限制：存档里的主题不能回复；如果你希望所有主题都允许回复，不能用主题存档分表，只能做post帖子分表，thread仍然单表。

坑：很多站长误以为主题分表后所有主题都可以回复，存档表主题是只读，这点一定要注意。

三、post帖子分表（pre_forum_post 楼主正文+所有回复）

pre_forum_post 才是正文存储表，压力远大于thread主题表。
即使主题只有100万，每个主题平均10条回复，post就1000万行。

• 单张post表建议上限：500万pid以内，超过建议分表（pre_forum_post_0、post_1…）。
• X3.5帖子分表有历史bug风险：升级后回复错位（tid的tableid索引异常），分表前务必备份数据库。
  社区普遍反馈：分表维护成本高，插件、采集容易不兼容，非超大站尽量避免开启分表。

四、不同规模完整硬件&架构参考（允许全部主题可回复，不使用只读存档）

①小规模：≤30万主题，日均发帖几百

• 架构：Web+MySQL同一台机器
• 硬件：4核8G，SSD 100G
• MySQL：MySQL8.0 / MariaDB10.4；innodb_buffer_pool_size=5‑6G
• 优化：开启dz内置缓存；尽量少装插件；图片走CDN。

②中等规模：30‑80万主题，日均发帖几千

• 架构：Web与数据库分离两台服务器
• Web：4核8G SSD；PHP7.4‑8.1，开启Redis缓存dz数据
• DB库服务器：8核16G SSD；innodb_buffer_pool_size=10‑12G
• 不要开启主题存档分表；监控post表行数，接近500万pid评估post分表风险。

③大规模：80‑150万主题，全部主题允许回复（不做只读存档）

thread仍然单表，重点扛post压力

• 架构：Web多机 + 独立高性能DB服务器，可做MySQL一主一从读分离
• DB服务器：16核‑24核，内存32‑64G，高速SSD；innodb_buffer_pool_size=24‑48G
• 必须接入Redis缓存；关闭dz后台自动统计定时任务；定期维护表碎片；
• post表超过500万pid，评估post分表（风险高，要测试插件兼容性）。

④超大规模：>150万主题

两条路二选一：

1. 使用主题存档分表：老主题移入存档（失去回复能力），主表控制在80万以内，总主题可以到300‑500万；运维简单。
2. 全部主题允许回复：需要深度二次开发，原生X3.5能力有限，不建议原生程序硬扛。

五、关键注意事项（踩坑重点）

1. thread主题表和post帖子表分开看待：很多站点主题不多，但回复巨多，卡死在post表，不是thread表。
2. 主题存档分表 ≠ post帖子分表，两个独立功能，不要混淆。存档表主题不能回复，这是很多人踩坑点。
3. post帖子分表风险：很多采集、插件、第三方工具不兼容分表，升级程序容易出bug，非必要不开分表。
4. InnoDB最重要参数：innodb_buffer_pool_size，尽可能给大内存，数据库性能第一要素是内存，其次SSD磁盘IO。
5. 只备份数据库拿不到图片附件；备份必须同时备份data/attachment/目录。
6. X3.5官方已经停止更新，超大站点建议评估升级X5。

六、快速决策建议

1. 主题预计小于80万，且希望所有帖子都能回复：不要开启主题存档分表；优先提升数据库内存、SSD、Redis缓存。
2. 主题超过80万，老帖不需要回复：开启主题存档分表，老主题移入存档，主表控制80万以内，是原生X3.5最稳妥的方案。
3. 主题超过80万，并且历史帖子全部还需要回复：原生X3.5压力很大，需要独立高配DB，谨慎评估post分表的风险。

我真的是真人

文字数据库
附件本地