阿里云

请作为项目交付负责人，根据已有材料推进 项目名称，把工作拆成可执行、可验证的任务。

输入：业务目标和用户 业务目标；现有工程与运行环境 工程现状；本次范围 交付范围；技术栈 技术栈；工期和角色分工 协作约束；已有验收要求 验收要求。

1. 先核实业务事实、现有能力和本次变更边界，分开已确认需求、合理假设与待决事项。把每个需求对应到具体角色、业务动作、输入和结果，避免用抽象口号代替验收条件。
2. 按依赖安排需求梳理、信息架构、交互与 UI、接口契约、数据模型、实现、联调、测试、上线。Java/Python、Vue/小程序按实际项目选用，可并行的任务并行，不能强行要求所有技术都出现。
3. 为各阶段写明输入、责任角色、产出和进入下一阶段的条件。特别检查状态机、权限与租户范围、字段口径、分页统计、错误处理和并发场景是否在产品、接口与数据库之间一致。
4. 将开发任务落到可识别模块，列出依赖、风险和可独立验证的完成标准。新增数据库表的全部字段要有详细业务注释；页面信息有秩序，文案直接服务业务操作，避免装饰性说明。
5. 组织与风险相称的检查、构建、测试环境验证和生产发布。记录需求版本、代码版本、制品版本、配置差异和测试证据，让最终上线内容可以追溯到本次范围。
6. 交付前核对数据变更兼容性、恢复方案、运行日志、健康检查及关键业务回归。未经实际验证的内容写明未验证及原因，不用计划中的动作充当已完成证据。

输出：一页业务范围、按依赖排列的任务表、各阶段交接清单、验收矩阵和当前阻塞项。优先继续不依赖待决事项的工作，仅对真正影响业务结果的问题请求澄清。

依据与范围
- [阿里云云效 · 如何通过云效进行主机部署](https://help.aliyun.com/zh/yunxiao/use-cases/how-to-deploy-hosts-through-cloud-effect)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文是云效产品流程，不是阿里内部统一研发制度；跨角色分工以及数据库、缓存兼容与补偿检查属于本站工程补充。

全流程目录
以下条目可分别使用；Java、Vue、小程序、Python 根据项目技术栈选用。
1. [需求范围](https://prmpts.lukeliu.me/prompts/cmts50jvw0077mqbec2k8oyul)
2. [需求说明与研发拆解](https://prmpts.lukeliu.me/prompts/cmts50jvz007bmqbe96119kry)
3. [业务流程](https://prmpts.lukeliu.me/prompts/cmts50jw3007fmqbev368mott)
4. [UI 布局](https://prmpts.lukeliu.me/prompts/cmts50jwf007vmqbeo10el4wr)
5. [Java 接口](https://prmpts.lukeliu.me/prompts/cmts50jsn003fmqbem2r0yu8u)
6. [Vue 表单](https://prmpts.lukeliu.me/prompts/cmts50juo005nmqbem9miiv32)
7. [小程序登录](https://prmpts.lukeliu.me/prompts/cmts50jv7006bmqbedywdvzzd)
8. [Python 接口](https://prmpts.lukeliu.me/prompts/cmts50jvg006nmqbevejtku4p)
9. [MySQL 建模](https://prmpts.lukeliu.me/prompts/cmts50jtj004bmqbewfpmkn62)
10. [Redis 设计](https://prmpts.lukeliu.me/prompts/cmts50ju0004vmqbe58dpb66y)
11. [测试用例](https://prmpts.lukeliu.me/prompts/cmts50jwy008jmqbetrem99f3)
12. [持续集成](https://prmpts.lukeliu.me/prompts/cmts50jxo009jmqbe08lqetoo)
13. [发布验收](https://prmpts.lukeliu.me/prompts/cmts50jx7008vmqbe8hlhldxe)
14. [备份恢复](https://prmpts.lukeliu.me/prompts/cmts50jxu009rmqbe3pp1q41q)
15. [Nginx HTTPS](https://prmpts.lukeliu.me/prompts/cmts50jxa008zmqbe6wjhhx0t)
16. [分批发布与回滚](https://prmpts.lukeliu.me/prompts/cmts50jxr009nmqbec1s2cpsw)
17. [故障复盘](https://prmpts.lukeliu.me/prompts/cmts50jxx009vmqbes5wf9lc8)

请协助处理或复盘 故障名称，以事实和业务恢复为中心，形成可交接的处理记录。

输入：用户症状和影响时间 故障现象；服务拓扑 服务范围；日志、指标和请求样例 证据资料；变更记录 近期变更；已执行动作 处置记录；当前恢复状态 当前状态。

1. 明确受影响业务、用户范围、发生时间和当前负责人，区分完全不可用、部分失败、性能下降与数据错误。未知影响不写成零影响，未经确认的原因标为假设。
2. 用统一时区整理触发、发现、响应、处置、恢复和复验的时间线。每个节点注明动作、执行者、依据与观察结果，将事后推断和当时已知事实分开。
3. 关联入口、应用、数据存储和外部依赖证据，比较故障前后的变化。对每个候选原因写出支持与反对信息，避免仅因先后发生就认定因果关系。
4. 按影响和可逆性比较回退、隔离、降级、扩容等恢复措施，注明停止条件与数据一致性代价。保留必要证据后，在既定授权范围内执行最合适动作并继续观测。
5. 通过关键业务请求及用户影响指标确认恢复，单个健康接口成功不能替代业务恢复。核对积压任务、重复处理、数据修复及仍需人工跟进的事项。
6. 复盘触发因素、放大因素、发现延迟和恢复障碍，为每项改进指定负责人、完成日期及可验证结果。输出简洁的值守交接，不用追责性描述代替技术与流程分析。

输出：当前事实与待核实项、时间线、根因证据链、恢复确认、数据善后及改进任务表。如需对外说明，按受众另写业务影响和恢复进展，不泄露凭据与内部敏感信息。

依据与范围
- [阿里云 · 管理故障的全生命周期](https://help.aliyun.com/zh/oic/user-guide/how-to-manage-faults)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文为运维事件中心使用流程，不将产品状态字段宣称为所有企业强制标准。

请为 业务系统 制定备份与恢复演练，目标是证明关键业务可恢复，而非仅证明备份文件存在。

输入：数据库与存储清单 数据资产；应用及配置清单 应用资产；现有备份与时间记录 备份情况；可接受数据损失和恢复时间 恢复目标；隔离演练环境 演练环境。

1. 建立业务对象与数据库、文件附件、对象存储、配置、密钥引用的对应关系，区分可重建缓存与不可丢失数据。核查各份备份是否处于可兼容时间点，避免数据库恢复后附件缺失。
2. 根据实际数据库版本和部署方式选择受支持的备份方法，注明全量、增量及日志依赖。运行中的数据目录不能仅凭普通文件复制就认定一致；恢复能力须来自可检验的工具结果。
3. 校验备份状态、体积、校验值、加密和访问权限，确认恢复所需密钥可获取但不会进入公开报告。对备份留存和异地副本提出与恢复目标匹配的建议。
4. 在隔离环境恢复数据库、文件和应用，禁止演练实例连接生产写接口。核对定时任务、消息消费、回调和通知，防止演练触发真实业务副作用。
5. 以实际业务样本验证登录、查询、附件、关键记录数量与关联关系，核对权限和租户范围。记录恢复开始、数据可用、应用可用和业务验证完成时间，据实计算恢复耗时。
6. 将实际恢复点与故障假定时间比较，评价是否达到目标。整理缺失资产、失败步骤、负责人和复验日期；演练结束按既定范围处置临时资源，保留必要证据。

输出：备份资产矩阵、隔离恢复顺序、业务验证清单、实测恢复时间与数据损失范围、改进任务。没有真实演练数据时只给计划，不承诺零丢失或固定恢复时长。

依据与范围
- [阿里云 · ECS 容灾故障演练](https://help.aliyun.com/zh/cloud-backup/user-guide/fault-drill)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文要求已有容灾复制及恢复点；本模板扩展到自建项目恢复演练，不能承诺同等恢复能力。

请为 发布版本 制定可以执行和回退的发布方案，依据真实拓扑选择全量、分批或灰度方式。

输入：服务实例和流量入口 部署拓扑；变更清单 变更内容；数据库与缓存变更 数据变更；当前及目标制品 制品版本；可接受影响 业务约束；监控基线 运行基线。

1. 列出应用、前端资源、配置、数据库和外部接口之间的兼容关系。标识必须按顺序执行的动作，单实例环境应说明停机或切换约束，不能伪称无损灰度。
2. 核对目标制品对应代码和测试证据，保存当前制品与配置版本。发布前检查容量、健康状态及所需备份的可恢复性，避免发布过程才发现没有可用旧版本。
3. 定义首批范围、流量比例、观察时长和负责人。继续或停止的标准应包含业务成功率、延迟、资源和核心流程结果；没有历史基线的指标先注明待测。
4. 对新增字段、字段重命名、删除、数据回填与缓存格式变更分别设计新旧应用共存方式。新增字段写明详细注释，应用回退前必须确认旧版本能读取当前数据。
5. 给出每批执行、验证和暂停步骤；已授权发布时依次记录结果。不要在首批异常尚未解释前扩大范围，避免自动重试重复执行不幂等的数据迁移。
6. 按故障类型指定回退目标、触发条件和数据补偿边界。回退程序不等于撤销所有数据库写入；验证回退后关键业务、异步任务、登录状态和静态资源版本。

输出：发布顺序表、分批策略、放行与停止条件、数据兼容说明、恢复步骤和执行记录。计划、已执行、已验证三种状态必须分开。

依据与范围
- [阿里云云效 · 如何通过云效进行主机部署](https://help.aliyun.com/zh/yunxiao/use-cases/how-to-deploy-hosts-through-cloud-effect)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文是云效产品流程，不是阿里内部统一研发制度；跨角色分工以及数据库、缓存兼容与补偿检查属于本站工程补充。

请为 工程名称 设计或审查持续集成流程，使发布制品能准确追溯到代码和验证结果。

输入：仓库结构 模块结构；运行语言与版本 构建环境；现有流水线 流水线配置；依赖管理方式 依赖方式；制品仓库 制品平台；部署目标 目标环境。

1. 识别 Java、Vue、Python、小程序等实际模块的构建入口、依赖锁定和环境约束。说明哪些结果依赖网络、外部服务或配置，避免把本机成功直接等同于流水线可复现。
2. 按代码检查、必要测试、构建和制品校验设置阶段。对每项说明失败条件、产出证据和适用模块；测试未执行或未找到测试必须准确记录，不能当作测试通过。
3. 建立提交版本、流水线编号、制品名称、唯一版本和校验值的映射。禁止用同一个发布版本覆盖不同内容；云效通用制品仓库按其版本约束处理，其他仓库先核实覆盖策略。
4. 审查构建缓存与依赖缓存的键和失效条件，避免命中旧分支或不兼容环境。凭据从受控配置读取并限制用途，不打进前端产物、镜像层或日志。
5. 使用同一已验证制品向测试与生产晋级，环境差异外置并可追踪。检查前端构建时注入值是否已固化，不能把含测试环境地址的产物直接视为可部署生产。
6. 用一条正常提交和一个真实的失败条件验证流程，确认错误能阻止后续发布并保留诊断信息。记录制品下载后的校验方式、保留策略及回滚时如何选择准确版本。

输出：阶段及检查表、必要流水线配置、制品元数据示例、失败验证与版本追溯步骤。以实际工具和仓库版本为准，不编造平台不存在的配置字段。

依据与范围
- [阿里云云效 · 上传通用制品仓库](https://www.alibabacloud.com/help/zh/yunxiao/user-guide/upload-general-product-warehouse)
核验日期：2026-09-08。依据公开资料改写的执行模板；适用于云效通用制品仓库；其他仓库须核对各自版本策略。可复现构建、缓存隔离、制品晋级与失败验证属于本站工程补充。

请为 业务系统 设计能排查真实接口问题的 Nginx 日志和指标，兼顾查询效率与敏感信息保护。

输入：现有日志样例 日志样例；接口清单和路由规则 接口规则；观测平台 日志平台；业务成功定义 成功口径；流量规模与保留要求 容量要求。

1. 核查字段是否能串联入口、上游与应用，包括时间、请求标识、方法、规范化路径、状态、上游地址及耗时。标明各字段的类型、单位、时区和缺失值处理。
2. 按业务接口归并动态路径，避免订单号和用户编号造成维度无限增长。区分静态资源、健康检查、业务请求与内部调用，不让健康流量稀释失败率。
3. 对状态码、耗时分位数、请求量及流量分布分别定义分子、分母、时间窗与样本边界。HTTP 200 与业务成功要分开，不能由网关单独推断业务事务完成。
4. 根据真实日志编写最少量查询示例：失败最多接口、慢接口、指定请求轨迹以及变更前后对比。使用 SLS 时核对索引和查询语法，使用其他工具时给等价实现，不混用语言。
5. 设置基于历史基线、持续时间和最小样本量的告警候选条件。分别处理低流量误报与突发流量影响，说明告警后第一步应查看哪一段链路；没有基线时先给采样计划。
6. 检查 URL 参数、认证头和日志正文中的凭据及个人数据。制定必要字段脱敏、留存、访问权限和磁盘轮转方案，并以一条真实脱敏请求验证端到端检索。

输出：字段字典、指标口径、查询样例、告警条件建议和验证结果。所有百分比与阈值注明数据依据，不虚构流量统计。

依据与范围
- [阿里云 · 采集 Nginx 访问日志进行网站情况分析的案例](https://help.aliyun.com/zh/sls/collect-and-analyze-nginx-access-logs/)
核验日期：2026-09-08。依据公开资料改写的执行模板；SLS 查询语法不能直接当作本地日志命令；指标口径需按业务定义。

请定位 故障时间段 内 受影响接口 出现的 502/504，优先找到证据，再提出最小恢复动作。

输入：部署拓扑 链路拓扑；访问与错误日志 脱敏日志；最近变更 变更记录；上游健康和资源数据 运行指标；复现请求 请求样例。

1. 对齐各节点时区与故障窗口，记录用户症状、入口响应和影响比例。先确认实际链路是否包含 CDN、负载均衡和多层 Nginx，不能仅凭响应页面判断出错层。
2. 关联同一请求的入口状态、上游状态、连接与响应耗时。区分 Nginx 无法连接、上游返回错误、上游关闭连接和等待超时；日志缺少字段时明确证据缺口。
3. 从实际代理节点核对 DNS、目标协议、端口、路由、防火墙、监听地址与 Host。分别解释拒绝连接、静默丢包及 TLS 握手异常可能产生的现象。
4. 结合应用日志查看线程池、数据库连接池、外部依赖、内存和重启记录。寻找同时间的饱和、锁等待或超时传播，不把所有 504 归因于 Nginx 超时参数。
5. 比较最近版本、配置、证书和网络策略变更。为每个候选原因给支持证据、反证、只读验证方法及影响范围；先处理最可能且可验证的原因。
6. 给恢复动作及停止条件，说明对在途请求和数据一致性的影响。修改后复测同一请求，观察约定窗口并核对业务结果；问题消失但根因未证实应分别记录。

输出：故障链路图、事实时间线、候选原因表、恢复与回退方案、修复前后指标对照。没有证据支持时不要批量重启服务，也不要宣称已找到根因。

依据与范围
- [阿里云 · CDN 回源异常排查](https://help.aliyun.com/zh/cdn/user-guide/back-to-origin-troubleshooting)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文针对 CDN，排查时应先确认实际是否有 CDN 层。

请审查 Nginx 到业务服务的完整请求链路，定位路由冲突和代理配置问题，给出与当前环境一致的修改。

输入：入口域名与请求样例 入口请求；Nginx 完整相关配置 网关配置；前端路由和 API 前缀 路径约定；上游地址与监听范围 服务拓扑；是否包含 CDN、负载均衡或 OSS 外围组件。

1. 画出浏览器到实际服务的路径，注明每跳协议、端口、Host 和 URI。先识别已有配置继承和 location 匹配关系，再判断命中的站点。
2. 分别跟踪首页、前端深层路由、API、上传与静态资源。用具体请求展示转发前后 URI，核查 proxy_pass 路径及末尾斜杠是否符合接口契约，避免把接口错误转成前端首页。
3. 检查上游 Host、HTTPS SNI 和原始协议的传递。使用 OSS 时按其域名要求验证；普通 Java、Python 服务按实际虚拟主机约定处理，不机械复用 OSS 示例值。
4. 明确可信代理名单和真实客户端地址的来源。审查应用对转发头的信任边界，避免直接信任公网客户端伪造的地址或协议头；检查认证信息是否被不必要地复制到第三方上游。
5. 根据实际响应规模、并发、上传和业务超时确定连接复用及缓冲策略。分别说明连接失败和慢响应的观测办法；不要用统一的大超时掩盖应用瓶颈。
6. 对修改前后分别执行同一请求矩阵，校验状态码、响应类型、重定向地址和关键业务内容。补充同机其他站点的回归检查及配置恢复步骤。

输出：请求路径对照表、按证据排序的问题、必要配置差异、验证请求与预期响应。没有实际请求证据时，只提供诊断假设和下一步取证方法。

依据与范围
- [阿里云 · Access OSS through an ECS Nginx reverse proxy](https://www.alibabacloud.com/help/en/oss/user-guide/access-oss-through-ecs-reverse-proxy)
核验日期：2026-09-08。依据公开资料改写的执行模板；原文限定 OSS 代理场景；普通业务反向代理的检查步骤为本站扩展。

请依据真实执行证据编写简明版本测试报告。输入：版本与需求范围、测试计划、用例执行记录、缺陷及复测记录、环境信息、团队验收条件、已知未测范围。报告供业务负责人判断交付准备情况。

报告中的用例和缺陷应能追溯到测试计划与执行记录；版本结论按团队验收条件判断，不代替业务签收或上线批准。

执行步骤：
1. 明确报告对象、版本、测试环境、执行时间和数据截止时间，核对每份记录所属版本。不同构建或环境的结果分别列出，不用旧版本通过结果替代当前版本。
2. 按用例 ID、构建版本、环境、终端、角色及关键数据集组合分组，仅在同组内归并重复执行并保留历史。跨组失败分别保留，不能用 Vue 端或管理员通过覆盖小程序端或普通角色失败。统计区分用例数与执行实例数，明确通过、失败、阻塞和未执行口径，给出可复算数量。
3. 将已确认需求逐项映射到对应执行证据，列出没有用例、没有执行记录、只有静态检查或只测前端的范围。构建成功、页面可打开和核心业务通过应分别表述。
4. 整理未关闭缺陷的影响对象、业务后果、临时措施和复核状态，检查所谓已修复是否有对应版本的复测证据。只有修复说明而没有执行记录时标为待验证。
5. 按团队已提供的验收条件逐项判定满足、不满足或证据不足。条件缺失时提出建议并单独列出，不能先自行设门槛再宣称版本已经满足业务验收。
6. 生成发布准备建议和后续工作，每项写责任角色、所需证据和重新评估条件。需要正式业务确认的事项清楚列出，不冒充项目负责人已经批准发布。

输出：版本与环境、覆盖范围、执行数量及统计口径、需求验证表、遗留缺陷、未测或阻塞范围、验收条件判定、交付建议与后续动作。用短句和必要表格，不添加夸大总结。

验收：所有数字可从执行记录复算；未测和阻塞不会计为通过；所有通过结论对应当前版本证据；风险可理解可追踪；没有伪造性能、兼容性或安全结论。

信息边界：没有执行数据时只输出待填写框架和材料缺口，不填示例通过率；本任务不自动发布版本、替业务签收或向团队发通知。

参考来源（核验于 2026-09-08）：
- [云效 Testhub：快速入门](https://help.aliyun.com/zh/yunxiao/user-guide/quick-start)

请制定本次迭代可执行的测试与回归计划。输入：版本变更、需求列表、系统依赖、用例库、测试环境及人员、发布日期约束、已知缺陷。计划范围必须与真实变更相对应。

将测试计划关联到当前项目和迭代，按变更选择用例并记录状态及缺陷；执行优先级、准入和退出条件以项目约定为准。

执行步骤：
1. 确认版本标识、变更模块、配置和数据变化，建立变更到业务链路的影响关系。缺少代码差异或依赖信息时列出证据缺口，不声称已经覆盖所有受影响模块。
2. 从用例库选择新功能、变更功能、关联功能和历史高风险缺陷对应的用例，记录入选原因与需求关联。未选中的相关用例说明理由，避免把回归范围简单设为全部或随意抽查。
3. 按业务阻断、数据正确性、权限边界和常用路径安排顺序，区分冒烟、功能验证和回归。结合接口、后台页面、小程序等真实终端列出环境和账号需求。
4. 为每组用例设置责任角色、执行窗口、前置数据和依赖，资源未知时使用待分配项，不编造具体人员承诺。环境、证书、域名和组件版本须对应被测版本。
5. 定义未执行、执行中、通过、失败和阻塞的含义，并说明失败与阻塞如何记录证据、关联缺陷及安排复测。复测只能覆盖实际修复版本，保留先前失败记录。
6. 提出本次版本的完成条件和剩余风险处理方法，统计状态时明确分母及去重方式。阻塞、暂缓或跳过不能被计作通过，不用高通过率掩盖核心场景未执行。

输出：测试范围与排除项、变更影响表、用例选择及顺序、环境和人员安排、执行记录规则、复测计划、完成条件、风险与缺口。时间安排注明依据与可调整条件。

验收：范围可追溯到变更；关键场景有负责人和前提；状态含义无歧义；回归对象明确；计划中的能力和资源有依据；未执行项可见。

信息边界：该任务产出计划，不自动执行测试或改动工作项状态；如果用户另行授权执行，必须依据真实运行记录更新结果。

参考来源（核验于 2026-09-08）：
- [云效 Testhub：测试计划](https://help.aliyun.com/zh/yunxiao/user-guide/test-plan-1)

请根据真实需求设计业务测试用例。输入：需求及版本、页面和接口说明、角色与数据范围、状态和业务规则、运行终端、现有用例。产出可供人工执行或继续编写自动化测试，不把编写用例等同于执行通过。

按产品模块组织用例，写清前置条件、操作步骤和预期结果；覆盖范围应与当前工程需求对应。

执行步骤：
1. 从需求提取可验证的业务规则，为每项规则保留需求编号及原文位置。区分正常功能、错误处理、权限、数据和兼容性，标注没有定义预期结果的规则缺口。
2. 按产品、模块、功能和场景组织用例，检查现有用例能否复用。删除仅名称不同但验证内容相同的重复项，并保留真正不同的业务边界。
3. 为关键业务写正常路径，注明角色、登录状态、组织、测试数据和前置记录。每一步操作应可重复执行，预期结果同时包含页面表现与必要的数据变化。
4. 补充必填、范围上下界、空值、重复、状态不合法、并发修改、网络中断和接口失败等适用条件。不存在业务需求的场景标为建议核实，不为凑数量添加无效用例。
5. 针对多组织或多租户系统，分别验证列表、详情、接口、导出和统计的数据边界。前端隐藏按钮不能替代服务端拒绝越权请求的预期结果。
6. 根据业务影响确定执行优先级和自动化候选，注明环境依赖及数据清理方式。涉及支付、删除或生产写入的验证先设计隔离条件，避免用真实业务记录凑测试材料。

输出用例表：编号、需求编号、模块、标题、优先级及理由、前置条件、测试数据、操作步骤、预期结果、环境依赖、执行状态。初始执行状态统一为未执行；另列规则缺口和建议。

验收：每项已确认规则有对应验证；步骤可复现；预期结果可观察；角色和组织边界明确；无伪造结果、截图或接口响应；不以用例数量代替覆盖质量。

信息边界：没有环境或执行权限时只生成用例；未知规则不能自行变成验收标准，自动化适用性也应说明依赖。

参考来源（核验于 2026-09-08）：
- [云效 Testhub：快速入门](https://help.aliyun.com/zh/yunxiao/user-guide/quick-start)

请审查需求是否具备进入研发或接受变更的条件。输入：需求当前版本、上一版或变更说明、设计及接口资料、数据和权限约束、迭代安排、团队已有评审规则。给出可操作的评审问题与责任建议。

评审内容和节点以团队现行规则为准，下面的检查维度用于补齐业务问题，不替代团队的决策流程。

执行步骤：
1. 确认审查对象、版本、材料日期和本次变更范围，对比前后差异。材料不完整时列出实际已读内容，避免以旧版设计稿审查新版需求却不说明。
2. 检查目标、角色、输入、业务规则、状态、失败恢复和验收条件是否齐备。每个问题指出具体条目及会影响的用户操作，避免只有“建议完善”等泛泛意见。
3. 分析变更对历史记录、统计口径、接口兼容、导入导出、权限和跨组织数据的影响。分别列出已证实影响、需查代码或数据才能确定的影响。
4. 检查设计、接口、前后端任务与测试准备是否相互匹配，找出责任空白和依赖顺序。没有人员和工期证据时只写责任角色，不替团队承诺完成日期。
5. 按业务损失与返工范围确定问题优先级，区分必须明确后才能开发的问题、可并行补充的问题和优化建议。优先级定义优先使用团队既有规则。
6. 给出逐项处理建议、补充材料、责任角色和复核条件，并形成进入研发、补充后复核或暂不具备条件的建议。未获得真实评审意见时不能标注任何人已同意。

输出：评审范围与材料、变更摘要、问题表、影响关系、待办清单、评审建议及其条件。问题表含编号、依据位置、具体影响、优先级理由、责任角色、关闭条件。

验收：每条问题可定位和复核；重大规则与权限影响没有被界面细节掩盖；结论基于当前版本；建议与团队真实决策明确区分。

信息边界：只进行材料评审，不自动推进工作项状态、替他人签署意见或发出上线通知；未知事实应保留为问题，不能用行业惯例冒充已确认规则。

参考来源（核验于 2026-09-08）：
- [云效 Projex：需求评审](https://help.aliyun.com/zh/yunxiao/user-guide/requirements-review)
- [使用项目协作创建并完成需求](https://help.aliyun.com/zh/yunxiao/user-guide/start-collaboration-within-a-project)

请将业务需求转成可交付研发的功能说明与工作项。输入：业务需求、已确认范围、现有系统或页面、业务规则及数据字典、项目与迭代约束、参与角色。面向产品、设计、前后端和测试共同阅读。

工作项需写清描述、负责人、优先级、项目和迭代，并关联设计、接口等研发资料；字段与流转规则以团队实际使用的系统为准。

执行步骤：
1. 建立需求编号和简短中文标题，写明业务背景、使用角色、进入条件和最终结果。每条只描述一个可独立验收的业务目标，复合目标先拆分再说明关系。
2. 逐项列出页面或接口的输入字段、来源、类型、必填条件、合法范围、默认值和校验时机。任何默认值须有业务依据；历史数据兼容规则未知时作为缺口保留。
3. 明确核心计算、状态变化、重复提交、并发修改和失败恢复规则，分别写正常路径与异常路径。凡涉及统计，注明时间范围、组织范围、状态过滤和去重口径。
4. 整理角色操作矩阵，分别定义查看、新增、修改、审批、导入和导出权限。说明数据可见范围及权限不足时的用户反馈，不把按钮隐藏当作完整授权实现。
5. 按设计、服务端、前端、数据调整和测试拆分实际工作，建立依赖与交付物。负责人可用已提供的人名或岗位，缺少人员安排则保留待分配，避免编造排期。
6. 将需求编号关联设计稿、接口、规则依据和验收用例入口，写出每项完成条件与变更影响。只建议需要的工作项，不把拆分结果冒充已经在云效创建。

输出：功能说明表、字段规则表、状态与异常分支、角色权限矩阵、研发任务及依赖、验收清单、待补充材料。工作项至少包含标题、范围、责任角色、依赖、交付物、优先级依据。

验收：开发能够识别输入、处理规则和结果；测试能够从每项需求形成用例；没有无来源字段和虚构工期；中文业务名称前后一致。

信息边界：现有代码与需求冲突时同时列出两者，并标明需要业务决策的差异；本任务默认不创建外部工作项或发送协作消息。

参考来源（核验于 2026-09-08）：
- [云效 Projex：新建需求](https://help.aliyun.com/zh/yunxiao/user-guide/new-demand/)
- [使用项目协作创建并完成需求](https://help.aliyun.com/zh/yunxiao/user-guide/start-collaboration-within-a-project)

请审查 Redis 客户端的超时重试策略，并设计符合业务语义的幂等处理。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：Redis客户端重连与业务重试；先确认客户端及版本，连接重试和命令重试分开处理。厂商示例参数不能当作本项目推荐值。

输入资料：客户端与版本、命令及业务语义、现有重试配置、请求总时限、并发写入规则、故障样本。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

将命令已执行但响应超时纳入分析，审查重试的幂等性，并防止多层重试放大请求。

检查步骤：
1. 列出哪些异常发生在连接、发送、执行或接收阶段，按现有证据区分确定未执行、确定执行和结果未知；网络超时本身不能证明写操作没有成功。
2. 逐条按业务结果审查命令重复执行的影响，特别检查递增、入队、计费和带过期语义的写入；即使命令形式相同，也要评估并发新值被旧请求覆盖的风险。
3. 追踪客户端、业务方法、接口网关和任务调度层是否各自重试，计算最坏请求次数与总耗时；为每个操作指定唯一的重试责任层。
4. 为可重试操作定义总期限、次数、退避及随机扰动，结合剩余预算和业务重要性决定何时停止；参数待压测时给出推导方式，不编造固定最优数值。
5. 对非幂等或结果未知的操作，设计业务请求标识、状态查询或对账路径，说明判重记录的生命周期与故障边界；不得仅套一把锁就宣称端到端恰好执行一次。
6. 仅在隔离测试环境或已明确授权的生产演练中验证发送前断开、执行后丢响应、主备切换及连续失败；优先使用代理或桩模拟故障，不扰动普通生产连接，记录业务动作次数、最终状态、请求耗时和重试放大量；验证恢复后积压不会再次冲击系统。

输出要求：交付命令重试决策表、重试责任与预算、最小代码或配置、结果未知处理流程及故障用例。决策表写明“可重试条件｜重复后果｜停止条件｜人工或自动对账入口”。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《Tair：客户端重试指南》](https://help.aliyun.com/zh/redis/use-cases/retry-mechanisms-for-redis-clients)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请排查 Redis Jedis 连接池容量和资源泄漏问题。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：Jedis连接池及Commons Pool管理的客户端；官方页面示例基于Jedis2.9.0，必须核对实际版本API和默认值，不将该示例作为依赖升级建议。

输入资料：Jedis与Commons Pool版本、连接池配置、借还连接代码、应用实例数量、QPS及命令耗时、实例连接上限、错误日志。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

结合应用规模、命令耗时和服务端限制评估池大小，核对借用资源是否归还；池耗尽不一定需要扩容。

检查步骤：
1. 准确区分连接建立失败、借用等待超时、连接已耗尽与命令执行超时，按首次出现时间关联应用发布、流量和数据库资源，避免把所有异常都解释为池太小。
2. 逐一核对正常、异常、提前返回和批处理路径中的资源归还，检查是否把Jedis实例跨线程共享或在长任务中持有；提出能定位泄漏的最小观测方式。
3. 统计每个应用实例、业务池与分片的连接总量，包含扩容、滚动发布时并存的实例，计算与服务端连接限制的关系，并保留必要余量。
4. 根据实际命令耗时与到达率估算所需并发连接，核对等待上限、空闲连接及检测配置；参数名称和时间单位必须匹配版本，不直接复制旧文档默认值。
5. 检查慢命令、网络、DNS和下游阻塞是否延长占用，分别说明调整池容量与消除根因的效果；需要预热时评估启动期间的集中建连压力。
6. 在代表性流量下验证借用等待、活跃连接、空闲连接、错误和服务端负载，覆盖突发、节点故障与恢复；记录每次配置变更和可撤回的旧值。

输出要求：输出异常分类、资源生命周期、连接预算、参数建议及验证结果。参数表使用“当前值｜版本依据｜建议值或区间｜推导条件｜验证指标”，不得只给一组所谓通用最优参数。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《JedisPool资源池优化》](https://help.aliyun.com/zh/redis/use-cases/jedispool-optimization)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请定位 Redis 热 Key 流量，并评审访问分散方案。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：Redis或Tair的访问热点处理；Key大小与访问热度分别判断。控制台能力和读写分离方案须核对实际实例类型与业务一致性要求。

输入资料：热点时间窗口、Key访问指标、读写比例、业务一致性要求、分片与客户端信息、峰值来源。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

定位单个 Key 所在的具体分片；选择热点复制或读写分离时，评估相应的一致性代价。

检查步骤：
1. 以业务入口和时间窗口确认访问集中在什么对象，区分单Key高频、单分片集中与全实例容量不足；离线数据大小不能作为访问频率的证据。
2. 结合应用采样与已有实例指标识别真正热点，记录读写比例、响应体大小、请求集中来源及下游行为；采集本身要有资源预算，避免无限记录所有请求。
3. 区分可短暂陈旧的读取与必须保持最新的状态决策，说明缓存未命中或热点失效时的回源承载量；写热点不要用只读扩容冒充解决方案。
4. 比较请求合并、业务限流、本地短缓存、热点副本或业务拆分，分别列出适用前提、更新成本与失败行为；不默认采用所有方案，也不只计算理论吞吐。
5. 为候选方案定义缓存更新、版本识别、失效与恢复流程，说明多副本之间可能短暂不一致时用户会看到什么，以及如何避免旧值长期残留。
6. 用正常流量、突发热点、热点切换和更新失败验证效果，记录单分片压力、用户延迟、错误和回源次数；上线先覆盖可控业务范围，保留快速撤回方案。

输出要求：输出热点证据、读写分类、候选方案对比、流程与验证矩阵。结论必须说明获得的容量改善与牺牲的一致性或复杂度，未经实测的收益仅作为待验证假设。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《Tair：大Key和热Key》](https://help.aliyun.com/zh/redis/user-guide/identify-and-handle-large-keys-and-hotkeys/)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请诊断 Redis 大 Key 问题，制定拆分、清理或转存方案。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：Redis或Tair的大对象治理；先确认版本和数据结构。UNLINK需核对Redis4.0及以后支持情况，厂商Top Key功能也有实例限制。

输入资料：实例版本与拓扑、异常指标、疑似Key样本、数据结构、增长与过期策略、业务恢复方式。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

同时检查值大小和集合规模；离线快照可辅助容量分析，但不能代表实时访问热度。

检查步骤：
1. 确认业务现象与发生时间，分别记录内存、网络、CPU、请求延迟和分片差异，先区分值过大、元素过多、无效数据增长及消费停滞，避免统称大Key后直接删除。
2. 根据现有权限选择控制台指标、业务样本或离线快照，列明数据时效和覆盖范围；需要在线扫描时设置时间窗口、节奏和停止条件，不默认全量扫描零影响。
3. 对疑似对象收集类型、大小或元素数、过期、增长速度与业务拥有方，区别样本字节长度和真实内存占用；诊断命令是否支持须对照当前版本。
4. 提出保留业务语义的拆分、压缩、清理失效成员或转存方案，逐一评估读取次数、原子性、更新复杂度与CPU成本；业务仍需要的数据不得当作无效数据清除。
5. 制定迁移期间新旧数据共存、读写切换与回退方式，删除前核对目标与恢复来源；异步删除或分批清理也要监控资源，不能承诺对线上绝无影响。
6. 在小范围演练并核对结果一致性，逐批记录数据量、失败、延迟与资源变化；根据证据扩大范围，最终为增长来源补上容量告警与生命周期管理。

输出要求：给出证据表、根因假设、方案比较、分批实施及回退步骤。每个Key使用脱敏样例，处置清单含业务归属、保留要求、验证方式和停止阈值，未识别归属的对象暂不执行清理。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《Tair：大Key和热Key》](https://help.aliyun.com/zh/redis/user-guide/identify-and-handle-large-keys-and-hotkeys/)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请根据业务访问和数据生命周期设计 Redis Key、缓存策略及数据结构。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：开源Redis或Tair兼容场景；需要明确单机、哨兵、原生集群或代理模式。Tair增强数据结构不作为开源Redis默认功能。

输入资料：缓存业务、权威数据源、数据结构与示例、访问量及更新频率、一致性要求、Redis版本与拓扑。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

检查 Key 与值的规模、序列化及集群分布，避免命名或 hash tag 造成倾斜。

检查步骤：
1. 明确Redis在该业务中承担可重建缓存还是唯一数据存储，逐项列出数据丢失、淘汰和节点故障后的业务后果，只有明确恢复来源后才能制定缓存失效策略。
2. 按读取、更新、批量访问和统计需要选择数据结构，说明单个对象与集合边界；估算一条记录、一个Key和全年增长的规模，不用条数代替内存字节数。
3. 给出Key命名表，覆盖业务前缀、环境、版本、实体标识及实际存在的租户维度；控制可读性与长度，避免把敏感信息直接作为可见Key。
4. 设计过期、续期、失效和淘汰后的处理，检查批量同刻过期是否会集中访问权威存储；缓存写入或失效失败时明确业务结果，不把命中率当作一致性保证。
5. 核对多Key操作在目标拓扑中的限制，以及hash tag能否导致大量对象聚集在同一分片；如需序列化升级，规划新旧格式的读取和退出顺序。
6. 生成正常读取、首次回源、更新失败、缓存缺失及容量增长的验证样例，观察延迟、回源量和内存变化；把文档建议阈值与当前业务实测限制分开展示。

输出要求：输出Key字典、数据结构方案、生命周期表、失败行为、容量估算与验收用例。字典需含示例、值定义、过期依据、增长上限、拥有模块和兼容策略，不填写未经测量的性能收益。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《云数据库 Tair（兼容 Redis）开发运维规范》](https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请设计 MySQL 读写分离方案，并核对各类读取的一致性要求。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：具备主库、只读实例或数据库代理的MySQL系统；阿里云代理路由规则须匹配实际版本，其他代理与应用自行路由应独立验证。

输入资料：业务读写链路、一致性要求、数据库拓扑、代理与驱动版本、事务代码、延迟监控、流量分布。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

使用 RDS 代理分流读取时，核对事务、DDL 等请求的专门路由规则。

检查步骤：
1. 将查询按业务后果分类，分别记录必须看到刚写结果、可接受短暂陈旧和纯历史统计的场景，给出业务能接受的延迟边界，不能用统一延迟数字替代业务判断。
2. 绘制每条链路的连接入口和目标节点，包含事务、批任务、后台管理与故障处理；核对真实配置和调用结果，不能仅凭“只读”方法名称认定已访问从库。
3. 检查提交后立即查询、跨请求查询、分页和状态确认的行为，说明复制落后时用户可能看到什么；对状态决策、库存或权限判断列出需要的保证。
4. 比较代理路由、应用显式路由和保持主库查询的候选，明确驱动连接复用、事务绑定及路由切换的限制；不为了分担读压力把所有查询都切到只读节点。
5. 定义只读节点延迟过高、失联或容量不足时的降级，计算回流主库可能增加的压力；将限流、延迟展示和主库读取的业务影响分别说明。
6. 写入后读取、延迟注入、节点故障和恢复场景只在隔离测试环境或已明确授权的生产演练中验证，普通线上审查只采集已有指标；记录实际节点与数据可见时间；优化验收同时检查业务一致性和主库、只读节点的负载。

输出要求：输出业务一致性分级、路由表、失败处理矩阵、配置修改范围和验收用例。每条路由列出触发条件、目标节点、可见性要求及降级方式；新增数据库字段必须附详细中文注释。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《RDS MySQL：什么是读写分离》](https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/what-is-read-or-write-splitting/)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请评审 MySQL 表结构变更及回退方案。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：MySQL结构变更评审。RDS的BRR增强功能须确认内核与配置条件，不声称自建MySQL默认支持，也不保证DDL完全无阻塞。

输入资料：现有DDL、目标变更、表规模、MySQL及内核版本、复制拓扑、应用兼容要求、维护窗口。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

使用 DMS 时核对多环境结构一致性；耗时 DDL 可能影响备库追赶，需要单独评估复制链路。

检查步骤：
1. 逐项比较当前与目标结构，写出业务目的及影响对象，包括应用读写、报表、定时任务、数据同步和备份恢复；核对各环境真实结构，不能只比较迁移文件。
2. 检查字段类型、长度、精度、空值和默认值的变化，找出历史数据中不满足新约束的记录；所有新字段必须写详细中文注释，定义枚举、单位及默认值含义。
3. 按目标版本评估变更支持的执行算法与锁行为，估算表重建、临时空间和持续写入的影响；没有演练证据时，不承诺“在线”就等于业务无感。
4. 核对主备与下游同步的兼容性，明确DDL执行期间和之后的复制监控；如果考虑厂商增强功能，单列前提，不将其替代应用兼容和恢复准备。
5. 设计先兼容后切换的发布顺序，区分新增、数据回填、应用切换及旧结构清理；说明每一步失败后的停留状态，不能假定反向DDL一定能找回丢失数据。
6. 在接近真实数据量的环境演练，记录耗时、锁等待、空间和复制延迟，再制定执行条件、终止条件及恢复验收；完成后比对结构并验证关键业务读写。

输出要求：交付变更差异、依赖影响、分阶段SQL、执行条件、回退或恢复办法及验收表。标明可直接回退与必须从备份恢复的差别，未演练步骤明确写“待演练”。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《数据管理 DMS：结构设计》](https://help.aliyun.com/zh/dms/design-schemas)
[阿里云《RDS MySQL：DDL复制延迟优化》](https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/optimization-for-ddl-replication-latency)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请定位 MySQL 慢查询与连接耗尽的原因。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：阿里云RDS MySQL或能提供对应观测数据的自建MySQL；DAS界面及增强功能不能假定所有实例具备。

输入资料：故障时间段、慢日志、实例监控、会话与事务信息、近期发布及参数变更、数据库版本与规格。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

结合资源、执行计划、批量任务和未结束事务等证据排查慢 SQL。

检查步骤：
1. 整理故障时间线，把请求延迟、错误、连接数和近期发布放到相同时间轴，区分数据库执行慢、排队等待和应用获取连接慢，不用单张CPU截图下结论。
2. 按出现时间及累计影响筛选代表性SQL，记录调用次数、扫描与返回信息、业务入口和参数；日志可能包含敏感数据，输出时只保留必要的脱敏样本。
3. 检查会话和事务等待关系，识别长时间未结束的事务、批处理及并发冲突；将阻塞者与被阻塞者分开，不能按运行时长直接批量终止会话。
4. 比较问题前后的结构、执行计划和数据分布，评估版本升级、数据增长及参数变更是否能解释现象；无法获取历史数据时标明证据不足。
5. 按影响和可逆性给出处置候选，分别说明限制入口、暂停具体任务、优化SQL或调整容量能解决什么；对每个动作规定观察指标与撤回条件。
6. 复核故障缓解后相同业务是否恢复，追踪连接和事务是否正常释放，补充缓存失效或流量再次上升的场景；把应急处置与永久修复分开验收。

输出要求：输出故障摘要、时间线、已证实原因和待查假设、处置表、修复与复核结果。每个结论关联具体观测，禁止把厂商示例阈值直接当成当前实例的正常标准。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[阿里云《RDS MySQL 慢SQL问题》](https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/troubleshoot-slow-sql-statements-on-an-apsaradb-rds-for-mysql-instance)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请评审 MySQL SQL 与组合索引的上线方案。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：MySQL表与查询，具体优化能力以MySQL版本及存储引擎为准。阿里云自动优化是有产品前提的可选能力，不默认启用。

输入资料：SQL及绑定参数、表结构与索引、执行计划、数据分布、调用频率和读写比例、MySQL版本。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

结合实际 SQL 评审索引，检查局部优化是否会使全局性能变差。

检查步骤：
1. 明确查询要返回的业务数据，记录租户或权限条件、排序稳定性、分页方式和最大结果量；先核对SQL语义，不能为速度删掉业务过滤条件。
2. 检查字段类型与参数类型是否一致，梳理等值、范围、关联和排序的组合；索引是否有效以目标版本计划验证，不把函数、非等值等语法一律认定无索引可用。
3. 读取现有计划和代表性参数，比较估算行数、实际可得的扫描信息及返回量；数据分布未知时提出采样方法，说明空值、热门值和历史数据可能改变选择性。
4. 提出最少数量的候选索引与改写方案，逐项说明服务哪些高频SQL、可否复用已有索引以及对写入和空间的影响；保留不改索引的基线方案。
5. 在相同数据与负载下比较正常参数、极端参数和深分页场景，核对返回结果一致；除目标查询延迟外，观察更新耗时、并发吞吐和资源使用。
6. 给出上线顺序、观察窗口及回退条件，索引创建与删除分开说明；如果有DAS建议，先判断其证据和适用范围，不把平台建议直接当成已批准变更。

输出要求：按SQL清单、证据、候选方案对比、最小DDL和验证计划输出。所有性能结论给出测量条件，未执行的优化只写预期；新增字段时必须补齐详细中文COMMENT。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[腾讯云《云数据库 MySQL 使用规范》](https://intl.cloud.tencent.com/zh/document/product/236/13390?lang=zh)
[阿里云《RDS MySQL 自动SQL优化》](https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/use-the-automatic-sql-optimization-feature-for-an-apsaradb-rds-for-mysql-instance)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。

请完成 MySQL 业务建模和详细字段设计。根据提供的项目资料给出具体结论、处理方案和验证方法。

适用范围：MySQL业务库设计；目标版本、字符集及部署方式以输入为准。DMS流程仅供有相应产品条件的项目采用，自建库可使用现有迁移工具。

输入资料：业务需求、实体与状态规则、主要查询及写入、数据量与增长率、现有DDL、MySQL版本及部署方式。

资料不足时，先列出最多3个影响结论的关键问题；可以继续的部分标明假设，无法确定的内容写“待核实”。不得编造文件、行号、调用链、性能数据或已完成的验证。

上线前审核 SQL；使用 DMS 结构设计时，核对多环境结构一致性。

检查步骤：
1. 先梳理业务实体、实体关系、生命周期和唯一性，区分当前状态、明细记录和历史事实，明确哪些数据必须长期保留，哪些可以归档。
2. 根据真实查询和写入路径确定表的边界，列出需要联查的对象以及是否存在租户或组织隔离；未确认的业务关系不能直接写成唯一键或非空约束。
3. 建立字段字典，说明业务含义、类型长度、单位、精度、是否为空、默认值和枚举值；金额、比例和累计量按业务范围计算精度，未知值不能随意填零。
4. 生成DDL时为每张表写中文注释，并为所有新字段写详细中文COMMENT，包含含义、单位或枚举、空值与默认值语义；禁止只重复字段名充当注释。
5. 把主键、唯一约束及索引分别关联到业务规则和代表性SQL，评估写入成本、历史重复数据及兼容性；不要仅凭字段名称批量添加索引。
6. 给出开发、测试、生产的结构比对与变更顺序，列出旧数据填充、约束生效和回退条件；用新增、修改、删除及边界值样例核对业务能否完整表达。

输出要求：交付实体关系的文字说明、字段字典、带详细中文注释的DDL、索引与查询映射、迁移步骤及验收用例。字段字典与DDL必须逐项对应，资料不足的字段保留待确认说明。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。

来源（核验日期：2026-09-08）：
[腾讯云《云数据库 MySQL 使用规范》](https://intl.cloud.tencent.com/zh/document/product/236/13390?lang=zh)
[阿里云《数据管理 DMS：结构设计》](https://help.aliyun.com/zh/dms/design-schemas)

整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。