Back to Details

planetscale-schema-recommendations-agent-loop

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Schema recommendations agent loop

Schema recommendations agent loop

Purpose

目标

Use PlanetScale schema recommendations as high-quality input to agents. Convert recommendations into safe implementation plans, issues, branches, migrations, or pull requests. Do not apply recommendations directly.
将PlanetScale schema建议作为高质量输入提供给Agent，将建议转化为安全的实施计划、议题、分支、迁移任务或拉取请求。请勿直接应用建议。

Inputs

输入信息

Collect:
  • Open schema recommendations.
  • Recommendation type.
  • Affected table, keyspace, schema, and query pattern.
  • Suggested DDL.
  • Supporting Insights evidence.
  • Application repository and migration system.
  • Engine: Vitess or Postgres.
  • Target branch.
收集以下内容：
  • 未处理的schema建议
  • 建议类型
  • 受影响的表、键空间、schema和查询模式
  • 建议的DDL语句
  • 配套的Insights证据
  • 应用程序仓库和迁移系统
  • 数据库引擎：Vitess或Postgres
  • 目标分支

Recommendation types to recognize

需要识别的建议类型

  • Add index for inefficient query.
  • Remove redundant index.
  • Prevent primary key ID exhaustion.
  • Drop unused table.
  • Upgrade legacy charset or collation.
  • Other DDL recommendation.
  • 为低效查询添加索引
  • 删除冗余索引
  • 防止主键ID耗尽
  • 删除未使用的表
  • 升级遗留字符集或排序规则
  • 其他DDL建议

Triage questions

筛选评估问题

For each recommendation, answer:
  • Is this still open and relevant?
  • Which query patterns triggered it?
  • Which application code paths generate those queries?
  • Is the recommendation safely expressible in the application’s migration framework?
  • Does the ORM/schema source of truth need to change?
  • Can it be tested on a non-production branch?
  • What is the expected impact on reads, writes, storage, and deploy time?
  • Is there a rollback or revert path?
  • Is there a competing recommendation or migration?
针对每条建议，回答以下问题：
  • 该建议是否仍处于未处理状态且具有相关性？
  • 哪些查询模式触发了该建议？
  • 哪些应用程序代码路径会生成这些查询？
  • 该建议能否在应用程序的迁移框架中安全实现？
  • 是否需要修改ORM/schema的可信数据源？
  • 是否可以在非生产分支上进行测试？
  • 对读取、写入、存储和部署时间的预期影响是什么？
  • 是否有回滚或撤销方案？
  • 是否存在相互冲突的建议或迁移任务？

Engine-specific implementation path

针对不同引擎的实施路径

Vitess

Vitess

Recommended path:
  1. Create or use a development branch.
  2. Apply the schema change to that branch only after approval.
  3. Open a deploy request only after approval.
  4. Use deploy request review to inspect schema, shard impact, data-loss warnings, lint errors, and conflicts.
  5. Use normal safe migration path unless instant deployment is explicitly justified.
  6. Deploy only after approval.
  7. Monitor Insights and anomaly state after deployment.
Default output before approval: issue or PR with migration proposal, not a live deploy request.
推荐路径：
  1. 创建或使用开发分支
  2. 仅在获得批准后，将schema变更应用于该分支
  3. 仅在获得批准后，提交部署请求
  4. 通过部署请求审核来检查schema、分片影响、数据丢失警告、语法检查错误和冲突
  5. 除非明确证明需要即时部署，否则使用常规的安全迁移路径
  6. 仅在获得批准后进行部署
  7. 部署后监控Insights和异常状态
批准前的默认输出：包含迁移提案的议题或PR，而非实时部署请求

Postgres

Postgres

Recommended path:
  1. Convert DDL into the application’s migration framework where possible.
  2. Test against a non-production branch.
  3. Run application tests and relevant query checks.
  4. Open PR.
  5. Apply production migration only after approval.
  6. Use backups/PITR runbook as recovery plan, not as a substitute for migration review.
Default output before approval: migration PR or issue, not production DDL.
推荐路径：
  1. 尽可能将DDL转换为应用程序迁移框架支持的格式
  2. 在非生产分支上进行测试
  3. 运行应用程序测试和相关查询检查
  4. 提交PR
  5. 仅在获得批准后执行生产环境迁移
  6. 将备份/PITR运行手册作为恢复计划，而非替代迁移审核的方案
批准前的默认输出：迁移PR或议题，而非生产环境DDL语句

Codebase correlation

代码库关联

When a repository is available:
  • Search for the table and column names.
  • Search for ORM model definitions.
  • Search for migrations.
  • Search for query fingerprints, route tags, job names, and controller/action names from Insights.
  • Identify whether the recommendation should be implemented in database DDL, ORM schema, raw migration, or application query code.
当可访问代码仓库时：
  • 搜索表名和列名
  • 搜索ORM模型定义
  • 搜索迁移任务
  • 搜索Insights中的查询指纹、路由标签、任务名称以及控制器/操作名称
  • 确定建议应在数据库DDL、ORM schema、原生迁移任务还是应用程序查询代码中实现

Safety checks before proposing implementation

提出实施建议前的安全检查

Block direct application when:
  • The recommendation is stale or already addressed.
  • The affected table is small enough that the benefit is unclear.
  • The index would be redundant with an existing index.
  • The index would hurt write-heavy workloads without enough read benefit.
  • The table appears unused but repository references are ambiguous.
  • Dropping a table or index lacks owner confirmation.
  • The migration framework has a different schema source of truth.
  • The recommendation targets production and no branch/test plan exists.
出现以下情况时，禁止直接应用建议：
  • 建议已过时或已被处理
  • 受影响的表过小，收益不明确
  • 该索引与现有索引冗余
  • 该索引会给写密集型工作负载带来负面影响，且读取收益不足
  • 表看似未被使用，但代码库中的引用不明确
  • 删除表或索引未获得所有者确认
  • 迁移框架使用不同的schema可信数据源
  • 建议针对生产环境，但未制定分支/测试计划

Output

输出内容

For each recommendation, produce:
  • Recommendation ID/number.
  • Type.
  • Severity and expected benefit.
  • Evidence from Insights.
  • Affected schema.
  • Suggested DDL.
  • Application code owner or likely location.
  • Safe implementation path.
  • Validation plan.
  • Rollback/revert plan.
  • Approval requirement.
End with:
“No schema recommendations have been applied.”
针对每条建议，生成以下信息：
  • 建议ID/编号
  • 类型
  • 严重程度和预期收益
  • 来自Insights的证据
  • 受影响的schema
  • 建议的DDL语句
  • 应用程序代码所有者或可能的实现位置
  • 安全实施路径
  • 验证计划
  • 回滚/撤销计划
  • 审批要求
结尾需标注：
“No schema recommendations have been applied.”