三十个站的站群，光基础台账就是三十行乘二十列：域名、服务器、IP、备案号、CMS 版本、模板、栏目、核心关键词、发布节奏、续费日期、对应的账号。这些数据一开始都在一张表格里，谁建的谁记，等到第三个人接手，文件夹里躺着"台账-最新""台账-最新2""台账-修订版"，没人说得清哪个是准的。真正出问题的时候，往往是一个站到期没续费被回收，或者一批文章发到了错站的栏目里，回头查记录，查不到谁在什么时候改过哪一行。
站群管到一定规模，重点就从"站建得漂不漂亮"转到"数据管不管得住"。表格撑不住的部分，数据库能接住：字段有约束、操作有记录、批量动作有入口、多个站的数据能汇到一处比较。这一篇讲站群数据库怎么搭、表怎么设计、数据和站点怎么对应、合规上要注意哪几条，从最小的可用结构说起。
一、表格管站群，失效集中在这四个地方
表格不是不能用，站少的时候它是最快的。失效是从数据量和参与人数同时上来的那一刻开始的：一个人维护、十个站以内，表格够用；两三个人协作、二十个站以上，改错、漏改、版本分叉就会集中出现。常见的四种失效，几乎每个站群都碰到过。
- 版本分叉：台账靠文件传来传去，转发一次就多一个副本，合并的时候靠肉眼比对，比完还得再存一版"最终版"。
- 没有约束：日期写成"月底前后"、备案号少一位、IP 填成域名，表格不会拦你，等到要用的时候才发现数据不可用。
- 改动无痕：谁把价格改了、哪一站的模板换了、发布时间为什么推迟，表格不记录过程，出了问题只能靠回忆。
- 批量动作靠人：三十个站的续费提醒、发布状态同步、收录数据回收，表格的公式管得了一列，管不了一串关联动作。
这四种失效有个共同点，都不是粗心造成的，是工具的结构撑不住协作。表格是给单机单人设计的，站群是多人多站的协作场景，数据一旦变成"要经常查、多人改、跨站比"的东西，就该换个放法。
二、先把站群数据分成四层，再谈表怎么建
一上手就设计完整数据库，多半会设计过头。站群的数据看着杂，归归类其实就四层：台账层记录"有哪些站、站放在哪、什么时候到期"；内容层记录"每个站发什么、发到哪个栏目、什么时候发的"；运营层记录"发出去之后效果如何"；账号与费用层记录"谁能进后台、每年花多少"。四层数据的更新频率、参与人、敏感程度都不同，混在一张表里，才会越管越乱。
台账层：30 个站乘 20 个字段的基础数据点，一次录错一个，后面几十处引用都会连错
内容层：30 个站按每天一篇算，一个月的发布记录量级，人工核对不现实
运营层：按周采集一次收录与流量，一年下来单个指标就是上千条快照，趋势对比靠表格做不动
（以上数字按三十站规模的常见量级估算，用于说明数据层级的差别，你的实际数据量以自己站群为准。）
分层之后有一条判断标准：更新频繁、参与人多的层先入库，更新少、只有一两个人碰的层可以缓一缓。台账层和内容层变化最多、协作最多，优先做成数据库结构；账号与费用层敏感度最高，哪怕暂不入库，也要单独收口，不和其他数据混放。
三、五张表起步，先把站和内容管住
站群的库不需要一开始就设计得很全。落地经验看，五张表就能把最容易出岔子的部分管起来：站点表管"有哪些站"，栏目表管"每个站有什么栏目和模板"，发布任务表管"谁在什么时候给哪个站发了什么"，运营快照表管"采集回来的收录和流量数据"，留资表管"用户提交的电话和意向"。每张表只管一件事，表之间用站点编号关联。
-- 站点台账表：全群唯一的站点身份CREATE TABLE sites (site_id VARCHAR(16) PRIMARY KEY, -- 站点编号，全群唯一domain VARCHAR(128) NOT NULL UNIQUE, -- 主域名，做唯一约束server_ip VARCHAR(45),icp_no VARCHAR(64),cms_version VARCHAR(32),template VARCHAR(64),status TINYINT DEFAULT 1, -- 1 在运 / 0 停用 / 2 观察期expire_date DATE, -- 域名与服务器到期日created_at DATETIME DEFAULT CURRENT_TIMESTAMP,updated_at DATETIME ON UPDATE CURRENT_TIMESTAMP);-- 发布任务表：每次发布都留一条记录CREATE TABLE publish_tasks (task_id BIGINT AUTO_INCREMENT PRIMARY KEY,site_id VARCHAR(16) NOT NULL, -- 关联站点表column_id INT NOT NULL, -- 关联栏目表title VARCHAR(200) NOT NULL,keyword VARCHAR(100),status TINYINT DEFAULT 0, -- 0 待发 / 1 已发 / 2 失败publish_at DATETIME,operator VARCHAR(32), -- 操作人，留痕用INDEX idx_site_status (site_id, status),INDEX idx_publish_at (publish_at));-- 约定：站点编号 + 栏目编号 做业务唯一键-- 发布前先查后写，避免同一篇内容重复发到同一栏目建表时有几个细节值得一次做对。域名加唯一约束，重复录入会被数据库直接挡回来；状态用数字编码，别存"在运行""运营中""正常"这类自由文本，否则统计的时候先得做一轮清洗；每条记录都带创建时间和更新时间，改动留痕；删除用状态标记，不物理删行，历史记录还查得到。这几条做到了，表格时代最头疼的"数据不可信"问题就基本解决。
| 表名 | 存什么 | 关键字段 |
|---|---|---|
| 站点表 | 每个站的域名、服务器、备案、模板、状态、到期日 | 站点编号、域名（唯一）、状态、到期日 |
| 栏目表 | 每个站的栏目结构、绑定模板、核心关键词、责任人 | 站点编号、栏目编号、模板代号 |
| 发布任务表 | 每次发布的站点、栏目、标题、关键词、状态、操作人 | 站点编号、栏目编号、状态、发布时间 |
| 运营快照表 | 按周采集的索引量、收录状态、访问数据 | 站点编号、采集日期、指标名、指标值 |
| 留资表 | 用户提交的联系方式与咨询意向，来源页与时间 | 来源站点、来源页、提交时间、处理状态 |
留资表要单独对待，它存的是个人信息，访问权限、加密方式、留存期限都和其他表不同，这一点在第六章展开。五张表跑顺了再考虑扩展，加表比改表容易，表结构频繁变动才是站群数据管理里最伤筋动骨的事。
四、多个站的数据怎么汇到一个地方看
站群的数据落地有两种主流架构，选哪种取决于站点数量和安全要求。第一种是独立数据库物理隔离，每个站一套库，一个站出问题不牵连其他站，安全边界清楚，代价是运维量成倍上涨，十几个站以上就需要专职人手盯着；第二种是单库多表逻辑隔离，所有站共用一套库、用站点编号区分数据，维护成本低，备份和升级只做一次，适合站点多、预算和人手有限的情况。政务和大型集团的站群通常走第一种，中小规模的商业站群多数走第二种。
| 对比维度 | 独立数据库（物理隔离） | 单库多表（逻辑隔离） |
|---|---|---|
| 安全边界 | 一个站被攻击或出错，其他站不受影响 | 共用一套库，需要靠权限与备份策略划边界 |
| 运维成本 | 每站一套备份、升级、监控，人力投入高 | 备份升级只做一次，站点越多越省 |
| 数据汇总 | 跨站统计需要额外做数据同步 | 天然可跨站查询，一个 SQL 就能横向比较 |
| 适合规模 | 安全敏感的站群，站点数量可控、有专人运维 | 站点数量多、需要快速横向对比与批量操作的站群 |
不管走哪种架构，运营数据最终都要汇到一处才比得出来。各站独立部署的情况下，做法是给每个站开放统一的上报接口，按固定字段把发布记录、索引快照、访问数据、留资数量回传，中台按站点编号入库，字段口径统一后才能做横向比较。数据分散在各站后台，管理动作只能凭感觉；数据汇到一处，问题在哪个站、出在哪一天，一眼能定位。
规模再大一些的站群，靠人工拼接口不划算。UC 建站系统把采集和归集做进了内容中台：各站数据按统一口径回传，站点、内容、发布、收录、留资几类数据在同一个视图里管理，多站看板按站点、栏目、时间维度切换对比，哪个站的文章掉收录、哪个栏目的留资量异常，预警直接推到人手上；同时每个站独立部署、独立数据库，数据边界和物理隔离的思路一致，站点之间的数据不串。数量越多、参与人越多的站群，这套数据归集越省事。
五、数据入库之后，AI 能接手哪几件日常活
数据放进了结构化的库里，才有被自动使用的价值。表格时代很多事做不了，不是没人会做，是数据形态不支持：跨站统计要人工合并，异常发现靠翻页比对，批量任务靠一个个建。换成数据库之后，这几件事都可以交给 AI 和脚本接手，人的精力转到判断上。
查询这一步最能体现库的价值。过去要回答"上个月哪个站发布量最少、哪个栏目的留资转化最好"，得把几个表格翻一遍；现在把问题交给接了大模型的查询入口，转成 SQL 在库里跑，几秒钟出结果，还能直接导出成给老板看的对比表。异常发现同样直接：给到期前三十天的域名、连续两期掉收录的站点、堆积超过三天的失败任务各设一条规则，命中就推消息，不再靠人每周手动巡检。
批量任务生成和站群的内容节奏衔接最紧。栏目表里存着每个站的关键词与发布频率，AI 按这些字段生成未来一周的发布计划，写成待审任务入库，人到库里批量确认，系统按计划推进。数据清洗则放在入库之前：备案号格式统一、日期归一、重复标题标记，脏数据挡在门外，库里的数据才敢直接拿来做判断。
一周的数据流转大致是这条线：周一各站采集的数据回传入库，周二AI 跑异常规则、把可疑项列成清单，周三人核对清单、处理失败任务与掉收录的站，周五批量生成下周发布计划、确认入库，周日自动全量备份加异地归档。人和 AI 各管一段，中间有明确的交接点，数据不会在谁的手里断掉。
有一条边界要守住：AI 给的是线索和初稿，不是结论。凡是涉及价格调整、站点启停、对外发布这类动作，都要人看过数据后再拍板，AI 生成的判断要能和原始记录对上账，对不上就以原始数据为准。
六、权限、备份、日志，三件事定管理底线
站群的数据里混着两类东西：一类是站点的运营数据，丢了补得回来；一类是用户留资这类个人信息，管不好要出合规问题。两类数据的底线都落在三件事上：权限怎么分、备份怎么做、日志留多久。
几件事不要发生：留资数据被全公司都能打开的表共享；账号共用到没人说得清谁在用；网络日志留存不足法定期限；备份只做本地一份；人员离职后账号与密钥照旧有效。这些不是技术问题，是管理问题，成本不高，出事之后的代价都不小。
权限按最小可用分配，能看站点台账的人不必看留资表，能改内容的人不必动价格字段，敏感表单独授权、操作可追溯。备份按全量加增量的节奏做，异地存一份，重点在于恢复演练，只备份不练恢复，真出事的时候大概率恢复不起来。日志按《网络安全法》的要求留存不少于六个月，采集与查询分开存，长期审计的记录归档，写入前做好脱敏。留资这类个人信息，单独表、单独权限、加密存储，收集和使用不超出用户同意的范围，超过留存期限的按约定处理。
站群数据库放在什么服务器上合适？
库和站点分开放更稳妥：数据库放在不对外暴露的内网或安全组内，只允许业务服务器按端口访问；各站按独立账号连接、独立授权；公网访问一律走跳板或专线，不直接开数据库端口。站点数量多的时候，库的规格按写入频率估，别按站点数估，发布密集的站才是压力来源。
备份做到什么频率算够？
看数据的可重建程度。台账、栏目、发布计划这类核心结构，每天增量、每周全量；运营快照可以放宽到每周；留资数据按天备份并加密，恢复演练每季度做一次。判断标准很直接：假设库在今天全没了，你能在多长时间内把数据恢复到昨天，这个时间能不能承受。
七、迁移的次序，决定这套库能不能活下来
搭库最难的环节是历史数据往进搬。常见的翻车方式是"先做一个大而全的设计，再一次性迁移全部数据"，设计拖了两个月，迁移的过程中业务还在变，等库建好，结构已经对不上了。可行的次序是反过来：先把站点台账导进去，三十行数据几小时就能核完，当天就能用；栏目表按每个站的实际情况补，补一个站就核一个站；历史发布记录能导多少导多少，导不全的不强求，因为从启用那天起，新记录自然会积累。
库上线之后留一个每周核对的动作：新注册的域名有没有入表、停用的站状态改了没有、快到期的站有没有人管、各站的实际发布量和计划对不对得上。核对不追求一次全对，追求偏差能被发现。站群的数据管理是长期工程，库的价值会随着数据的完整度慢慢显现，一开始能查准域名和到期日，就已经比表格的版本混乱强出一截。
表格能记录数据，数据库能守住规则。站群做到几十个站的时候，值钱的不是那张越来越长的表，是"谁在什么时候改了什么、为什么改"这一整套能查证的过程。
回到开头那三个版本并存的文件夹。问题从来不是谁不认真，而是数据放错了地方。把站点、栏目、发布、运营、留资这五类数据按各自的结构放进库里，权限和备份各就各位，AI 的查询和预警接上去，站群的管理就从"靠人记住一切"变成"库记得住、人做判断"。规模继续涨的时候，这套结构能一直用下去，这也是它和表格最本质的区别。
"站群管得好不好，不看谁的表格排得整齐，看新来的人能不能在半小时内查清每一个站的状态。"
（文中数据量级按三十站规模的常见情况估算，仅用于说明层级差别；日志留存、个人信息处理与数据备份的具体要求以《网络安全法》《数据安全法》《个人信息保护法》及现行法规为准。）
