# Notebook作业调度场景下，手工调度和执行调度（单次运行）是不是一样的效果？
手工调度和执行调度（单次运行）效果不完全一样。
两种调度方式虽然最终都会执行一次作业，但在调度类型标记、依赖处理、并发控制、参数来源、运行身份、告警通知等方面存在明显差异。两种调度方式对比如[表1]。
- 手工调度：面向开发者的快速验证手段。其特点是忽略依赖、使用草稿参数和个人身份、不打扰任何人。代价是不能并发调试、产出不可被依赖、不进入生产资源环境。
- 执行调度：面向生产的执行方式。其特点是遵守依赖和互斥、使用已发布版本和生产身份、状态全链路可观测。代价是需要等待前置条件满足、产出对运维可见。
 表1手工调度和执行调度对比 
| 对比维度      | 手工调度（测试运行）                             | 执行调度（单次运行）                                   |
|:---|:---|:---|
| 使用场景     | 开发调试阶段，用于快速验证作业逻辑是否正确，无需等待调度计划时间。     | 作业配置完成后，需要立即执行一次（不修改周期调度配置），或通过API触发的单次运行。 |
| 操作入口     | 在作业开发页面单击"手工调度"按钮。                   | 在作业开发页面单击"执行调度"按钮。                          |
| 调度类型标记   | 实例监控中标记为"手工调度"类型。                      | 实例监控中标记为"正常调度"。                           |
| 前置依赖处理     | 忽略所有上游依赖，直接开始执行，无需等待父作业完成。             | 正常检查上游依赖，需等待所有父作业实例成功完成后才能执行。              |
| 并发控制     | 不支持并发：同一作业若已有手工调度实例在运行，不允许再次发起手工调度。 | 允许同一作业提交多次。受任务互斥配置约束（若配置了互斥则等待）。           |
| 参数来源     | 使用测试运行时手动填写的参数（手动输入的变量值）。             | 使用作业配置中定义的调度参数（SQL变量、脚本变量、常量、赋值算子传参等）。     |
| 作业版本      | 始终使用当前编辑中的最新版本，包括未提交的修改。              | 使用已提交（发布）的作业版本，不包含未提交的内容。                 |
| 资源环境（企业模式） | 开发态：使用开发环境配置的队列、数据库等资源，不做生产环境映射 。       | 生产态：通过资源映射使用生产环境队列和数据库配置。                 |
| 运行身份       | 以操作者本人的IAM身份执行。                       | 以作业责任人或工作空间委托身份执行。                       |
| 告警通知        | 取消或失败时不发送告警通知（视为调试行为，不打扰责任人）。        | 取消或失败时发送告警通知给作业责任人及相关订阅者。                  |
| 实例状态推送   | 不推送实例状态变更事件（启动、完成、失败等状态不对外广播）。        | 正常推送实例状态变更事件，运维监控可实时感知。                    |
| 历史数据清理     | 手工调度产生的等待队列数据不参与自动老化清理。               | 周期调度的等待队列数据按配置天数自动老化清理。                     |
| 可否被其他作业依赖 | 不能作为其他作业的依赖上游（调试性质，不产生可信产出）。         | 可作为其他作业的依赖上游，但"单次执行"类型作业不能被依赖             |
| 适用阶段        | 开发联调阶段。                              | 生产验证、临时补数、一次性任务执行。                         |