Discuz 论坛数据量过大时，官方推荐优先使用后台自带的“归档”功能将旧帖子迁移至归档表，而非直接手动分库分表。适用场景为帖子量超过百万级且查询变慢，风险边界在于部分插件可能无法读取归档数据且全站搜索需重新配置。
先说结论：Discuz 原生支持通过归档机制实现冷热数据分离，适合大多数中型论坛缓解数据库压力。
- 适合：帖子总量较大但近期活跃数据占比正常的论坛
- 先准备：完整备份数据库并确认插件兼容性
- 验收：验证前台发帖回帖正常且归档表数据可查
命令速用版
Discuz 分表操作主要通过后台界面完成，无需直接执行 SQL 分表命令，但可通过 SQL 检查表结构。
后台路径：管理中心 → 论坛 → 归档 → 设置归档条件
数据库检查：
SHOW TABLES LIKE 'pre_forum_thread_%';
若看到 thread_1 等后缀表，说明归档已生效。
为什么会这样
单表数据量过大会导致数据库索引效率下降和锁竞争增加。
Discuz 默认将所有帖子存在 `pre_forum_thread` 和 `pre_forum_post` 表中，当数据量达到百万级，写入和查询锁等待时间变长。归档功能将早期数据移动到 `_1`、`_2` 等后缀表中，减少主表索引体积，从而提升活跃数据的读写速度。公开资料中没有看到可靠的量化数据说明具体提升比例，但逻辑上减少了单表扫描范围。
分步处理
按顺序执行配置，每步完成后检查状态，避免直接操作数据库导致不一致。
1. 数据备份
操作前必须备份数据库，防止归档过程中断导致数据丢失。
动作：使用 Discuz 后台“工具”→“更新缓存”旁的备份功能，或 mysqldump 命令。
2. 设置归档条件
进入后台“论坛”→“归档”，设置归档规则，通常按时间或主题 ID 划分。
动作：勾选需要归档的版块，设置归档条件（如发帖时间大于 365 天）。
风险：不要一次性归档过多数据，建议分批操作。
3. 执行归档
系统通过定时任务或手动触发迁移数据。
动作：点击“开始归档”，观察进度条，若数据量大建议在低峰期执行。
检查：查看数据库是否生成 `pre_forum_thread_1` 等新表。
4. 配置定时任务
开启自动归档以维持主表大小。
动作：后台“工具”→“定时任务”，确保归档相关任务处于开启状态。
怎么验证是否生效
通过数据库表结构和前台查询表现确认归档是否正常工作。
1. 检查表结构
登录数据库执行 SHOW TABLES;，确认是否存在带数字后缀的归档表。
2. 验证前台访问
访问已归档的旧帖子链接，页面应能正常加载，URL 可能带有归档标识。
3. 搜索测试
使用站内搜索搜索旧帖子关键词，若无法搜到，需检查搜索索引是否包含归档表。
常见坑
归档后容易出现插件不兼容和搜索失效问题，需提前排查。
1. 插件读取失败
部分第三方插件硬编码查询主表名，无法读取归档表数据，导致显示空白。
对策：联系插件作者确认是否支持 Discuz 归档机制。
2. 全文搜索缺失
默认搜索可能只索引主表，归档数据无法被检索。
对策：在后台“搜索”设置中，勾选包含归档表或重建索引。
3. 数据统计偏差
后台显示的帖子总数可能不包含归档数据，导致统计数字变小。
对策：理解统计逻辑，以数据库实际行数为准。
常见问题
归档后会影响 SEO 收录吗？
只要页面能正常访问且返回 200 状态码，通常不影响 SEO。
归档的数据能恢复回主表吗？
支持恢复，可在后台归档管理中选择“解除归档”将数据移回主表。
手动分库分表比官方归档好吗？
手动分表风险更高，除非官方归档无法满足性能需求，否则不建议自行修改底层结构。