BigQuery执行DELETE语句报Cannot set write disposition相关错误

报错根因 #

这个报错的触发逻辑非常明确：你写的DELETE语句语法本身没有问题，问题出在作业配置冲突上。BigQuery 对 DML 类语句（DELETE/UPDATE/MERGE/带写入的INSERT）有强制规则——这类语句的目标表写入行为由系统自动管控，不允许用户在作业配置里手动指定write disposition（也就是WRITE_TRUNCATE、WRITE_APPEND、WRITE_EMPTY这类写入模式配置），write disposition本来就是给批量数据加载、导出类、非DML查询作业用的参数。
你遇到“昨天能跑今天报错”的情况，本质是今天执行作业时的配置残留了手动设置的write disposition参数，和SQL本身无关。

常见触发场景 #

• 网页控制台跑SQL时，之前配置过把查询结果写入指定表的设置没清空
• 用SDK、CLI、API提交作业时，请求体里残留了旧任务的writeDisposition字段
• 用调度平台（Airflow、dbt、Cloud Scheduler）跑任务时，全局模板默认给所有查询注入了writeDisposition配置

分步解决操作 #

1. BigQuery网页控制台执行的场景
   • 打开查询编辑器的设置面板，找到「查询结果写入目标表」的配置项
   • 把之前手动指定的输出表、写入disposition选项全部清空，恢复成默认的“返回结果到编辑器、不写入固定表”的状态
   • 重新执行你的DELETE语句即可
2. 代码/API/CLI提交作业的场景
   • 检查构造作业的请求参数，把整个writeDisposition字段从query配置块中移除
   • 错误配置示例：请求里给查询块加了"writeDisposition": "WRITE_APPEND"这类参数，直接删除该字段，只保留SQL本身的内容配置就可以
3. 调度工具触发任务的场景
   • 检查对应任务的配置模板，找到全局注入writeDisposition的逻辑
   • 针对DML类任务单独关闭这个配置，不要复用给批量加载任务的参数模板

注意事项 #

• 不要给DML作业手动配置任何write disposition参数，系统会自动处理表的写入锁、事务、元数据变更，额外加参数必然触发报错
• 如果是复用之前写的导出、批量加载任务的SQL模板，一定要清空模板里的输出配置、写入配置再跑DML

内容的提问来源于stack exchange，提问作者dbuzz