Cloud SQL调整查看者角色：导出权限已移除，自动任务要核对真实执行身份

2026年9月28日，Cloud SQL for MySQL发布记录公布一项不兼容变化：Cloud SQL Viewer、Basic Reader和旧版Basic Viewer角色移除cloudsql.instances.export权限。官方建议，需要保留导出能力的场景可使用Cloud SQL Editor，或在自定义角色中明确加入该权限。

AI概念配图，非真实界面/产品。

查看正常，不代表导出仍能运行

本文认为，首先值得检查的是长期没有改动的自动导出任务。运维人员仍能查看实例，不能证明定时作业使用的身份拥有同样权限。若作业依赖此次变更的角色，即使代码完全没改，也可能需要重新核对授权。

检查时建议从实际运行记录出发，确认调用的是哪个身份、针对哪个实例、返回什么错误。不要因为自己在控制台能成功操作，就把问题归到脚本或网络。人工用户、服务账号和被委派的执行身份可能是不同主体，排查材料应明确这一点。

这里也需要分清导出与其他数据保护流程。公告明确调整的是实例导出权限，不能由此推断所有备份机制都被关闭。团队应先画出现有流程：哪一步发起导出，哪一步把文件交给下游，哪一步确认文件可用，再定位受影响的动作。

按任务需要修复授权

官方列出的编辑者角色是一条可选路径，但本文建议先盘点任务究竟需要哪些动作。只为恢复一个导出流程就直接扩大整个身份的权限，可能给后续管理留下不必要的负担。已有自定义角色的团队，应把新增权限的用途与资源范围记录清楚。

修改前可让负责该作业的人确认它仍然需要运行，输出文件的接收方和保存位置也没有改变。某些历史导出任务已经无人使用，只是一直按旧计划执行。把所有失败任务一律恢复，并不一定符合当前的数据处理需求。

修改完成后，建议先运行一笔范围受控的验证任务，检查它是否真正生成了预期文件，再核对格式、记录范围与下游读取结果。接口返回成功只说明一段操作完成，业务依赖的整条导出链路仍需要验收。

把下一次计划运行当作最终确认

如果问题发生在定时任务，应继续确认它在原计划时点能够以原执行身份正常完成。临时用管理员身份手工导出成功，只能证明数据可以被导出，不能证明自动流程已经修复。交接记录应同时保留两次验证的身份与结果。

团队还可以为导出文件设置简单的到达检查，例如核对预期时间窗口内是否出现新文件，以及内容是否通过基本完整性检查。这样将来权限、目标存储或数据格式变化时，可以更早发现结果缺失。

此次调整提示维护者，角色名称是一种便于管理的权限集合，不能替代对关键动作的持续核验。对于重要流程，保留清楚的执行身份、所需权限与结果证据，能够让类似变更的影响更快被定位，也避免把临时绕过误当成长期修复。

来源与核验

Cloud SQL for MySQL官方发布记录（2026-09-28）。

本文于北京时间2026年10月1日核验。新闻事实来自上述官方资料，文中使用判断与实施建议为本站独立分析，后续状态以官方更新为准。