docs: require database load and index validation

AGENTS.md

@@ -8,6 +8,7 @@
 - 不改写已发布历史，不批量选择冲突的某一方；不明确的行为取舍需要负责人确认。
 - 所有变更通过 PR 进入 `main`，不得直接推送主分支；独立审核与最新内容的验证通过后由维护者合并。
 - 不提交凭据、私钥、环境秘密或真实业务数据；不把合并授权当成生产部署授权。
+- 新建或修改数据表、映射表、查询和同步任务时，必须按实际过滤、关联、排序和唯一性设计索引，用执行计划和有代表性数据验证负载；禁止无边界全表扫描、无节制并发和重复全量同步。
 - 开发机器使用中央系统数据库和公网 TLS Redis，无需安装本地数据库；生产部署必须先将代码通过 PR 合入 `main`，并在 `/opt/cangku/deploy.lock` 锁内从服务器 Git 工作区快进拉取和验证。
 - 最终交付报告实际分支、提交 SHA、验证结果及 PR 状态，不能将“已推送”报告为“已合并”。
 

仓库提交与合并规范.md

@@ -51,6 +51,21 @@ git status --short
 - 数据库迁移使用不重复的名称，兼容已有数据，不能修改已经执行的历史迁移来代替新增迁移。
 - 不提交 `.env`、私钥、令牌、真实业务数据、数据库备份、`node_modules` 或无关构建产物。示例配置只使用占位值。
 
+### 3.1 数据表、索引与映射负载要求
+
+开发者及 AI 新建或修改数据表、第三方数据映射、查询接口、报表或同步任务时，必须把数据库负载作为功能验收条件，不得等到上线后再补索引或限流。
+
+1. **按真实访问路径设计索引。** 根据 `WHERE`、`JOIN`、`ORDER BY`、分页、去重和幂等键设计单列或联合索引，明确联合索引列顺序和最左匹配规则。索引列的类型、长度、字符集和排序规则必须与关联列一致。不要添加没有查询依据的重复索引，也不能以索引过多换取“可能更快”。
+2. **映射关系必须稳定且可幂等。** 第三方主键、业务编码与系统主键应使用明确的标准化字段和唯一约束，需要多字段定位时建立与匹配顺序一致的联合唯一索引。禁止每次请求通过模糊匹配、字符串函数或全表扫描重建映射。
+3. **提交前验证执行计划。** 在隔离的测试环境使用 `EXPLAIN`；数据库支持且确认语句安全时可使用 `EXPLAIN ANALYZE`。检查实际命中索引、预估/实际扫描行数、回表、排序和临时表情况。不得在生产库上执行高负载的 `EXPLAIN ANALYZE` 或压测。
+4. **查询必须有界。** 使用限制列的字段选择和有上限的分页，大数据量优先使用基于稳定索引键的游标分页。避免 `SELECT *`、N+1 查询、无上限 `IN`、前置通配符模糊查询、对索引列包裹函数，以及没有范围条件的更新或删除。
+5. **同步任务必须分批、增量和可恢复。** 通过时间水位、版本号或稳定主键做增量读取，用唯一约束与 upsert 保证幂等；设置可控的批量、并发数、查询超时、重试退避和单实例锁。禁止每次启动全量扫描、无限并发、紧循环轮询或重复后台任务。
+6. **保护第三方云数据库。** 业务云库查询必须只取必要列和必要范围，并在系统库持久化必要的结果或增量水位，避免页面请求反复扫描远程大表。未获明确授权不得在第三方库执行 DDL、建索引或写入。
+7. **迁移必须考虑锁表和回退。** 针对大表新增索引、变更列类型或回填数据前，评估表规模、锁等待、磁盘增长和业务窗口；采用可分步的兼容迁移，并说明回退时是否会丢数据。
+8. **PR 必须附上数据库证据。** 说明表规模假设、索引定义及对应查询、执行计划摘要、扫描行数或耗时对比、同步批量/并发/超时参数、迁移与回退方式。无法获得有代表性数据时要标明限制，不得虚构性能结论。
+
+只有功能结果正确且负载证据可接受，数据表和查询变更才算完成。无法证明索引有效、可能对中央系统库或业务云库造成高负载时，保持 PR 待审核，不得部署。
+
 提交前逐项检查，并显式暂存文件；文件中混有不同任务时使用 `git add -p` 选择自己的改动。不要盲目使用 `git add .` 或 `git add -A`：
 
 ```bash
@@ -172,6 +187,7 @@ npm --prefix frontend run check
 - [ ] 已阅读本规范；当前仓库、目录、账号、任务分支和基线正确。
 - [ ] 没有覆盖、清理、暂存或提交他人的未提交修改。
 - [ ] 提交仅包含本任务内容，没有秘密信息、真实业务数据或无关产物。
+- [ ] 涉及数据表、索引、映射、查询或同步时，已验证执行计划、数据量边界和负载控制，并在 PR 记录真实证据。
 - [ ] 已同步最新主分支及远端任务分支，未强推、未改写已发布历史。
 - [ ] 已逐项审核最终差异；冲突处理保留双方有效行为，疑点已确认。
 - [ ] 已完成受影响的验证，记录准确结果和提交 SHA。

服务器部署规范.md

@@ -62,6 +62,8 @@ git diff --stat origin/main...HEAD
 5. 将任务分支推送到主仓库，创建 PR，经过审核和验证后合并到 `main`。这里的“先推送主仓库”指推送任务分支并通过 PR 合并，禁止直接推送 `main`。
 6. PR 合并后再次执行 `git fetch origin`，记录准备部署的 `origin/main` 完整 SHA。部署 SHA 必须与审核通过的最终提交一致。
 
+如果本次变更涉及数据表、索引、查询、数据映射或同步任务，部署者还必须确认 PR 已按《仓库提交与合并规范》记录索引与执行计划证据、分批/并发/超时边界、大表锁影响和回退方式。证据缺失、依赖全表扫描、可能对系统库或第三方云库造成不可控负载时，不得部署。
+
 有冲突时，AI 必须阅读共同基线和双方改动，保留双方仍然有效的行为。无法确定业务取舍时，停止该冲突的处理并请负责人决定。冲突解决后的代码必须重新测试、重新审核，不能沿用冲突前的结果。
 
 ## 4. 检查服务器是否正在更新