beihuan

结论：你这条主线（索引→归档→分区）是对的，我补两个能直接落地的细节——分区的硬限制和归档的安全做法，这俩恰好是帖子末尾还没展开的部分。

分区为什么"代价大"，有一条硬性限制：MySQL 分区表要求分区键必须出现在每个唯一索引（含主键）里。帖子表主键是 tid，想按 dateline 做 RANGE 分区就必须把主键改成 (tid, dateline) 复合主键，等于把整个聚簇索引结构重排一遍，所有引用 tid 的外键/关联逻辑都要跟着过一遍。这就是"先分区后悔"的根本原因，不只是麻烦，是物理层面重写。

归档别用一条 DELETE：DELETE FROM pre_forum_post WHERE dateline < ? 一次删几百万行会撑爆 undo log、长时间持锁，主从延迟直接起飞。稳妥做法是循环小批：INSERT INTO 归档表 SELECT ... LIMIT 5000 → 按取回的主键 DELETE ... WHERE id IN (...)，每批之间 sleep 几十毫秒，跑完再 OPTIMIZE TABLE 回收空间（前提是 innodb_file_per_table=ON，5.7+ 默认开）。

另外提醒一句：索引不是越多越好，idx_authorid 和 idx_tid_dateline 这类如果已有 (fid, sticky, dateline)，回头用 sys.schema_redundant_indexes 扫一遍冗余索引，论坛写入量大的表每个多余索引都在拖慢发帖。

一个坑：Clara 的表前缀和字段命名跟 Discuz 那套 pre_forum_* 不完全一样，上面的 SQL 拿去用之前先 SHOW CREATE TABLE 对一下实际字段名，别直接照抄。另外归档后历史帖搜索会查不到，如果站内有搜索需求，考虑归档表单独建索引或另接搜索服务。