安全执行CI/CD中DDL需精准授权：仅授予CREATE、ALTER、DROP等必要权限至目标数据库，禁用全局及高危权限；使用角色管理更可控；注意客户端版本≥服务端、权限生效需重连、脚本语法与引擎兼容性。
CI/CD 流程执行 DDL（如 CREATE TABLE、ALTER TABLE）时，不能直接给机器人账号授予 ALL PRIVILEGES 或 PROCESS 这类高危权限——它会绕过最小权限原则，也容易因误操作引发生产事故。真正安全可行的做法，是按「动作+对象范围」做精准授权，并配合工具层约束。
只授必要 DDL 权限，禁用全局权限
MySQL 8.0+ 支持细粒度 DDL 权限控制，应避免使用 GRANT ALL ON *.*。CI 账号只需以下几类显式权限：
-
CREATE、DROP、ALTER、INDEX权限，但仅限于目标数据库（如GRANT CREATE, ALTER, DROP ON `app_prod`.* TO 'ci_runner'@'10.20.30.%'） - 若需修改列注释，必须额外授予
REFERENCES权限（MySQL 8.0.16+ 要求该权限才能执行ALTER TABLE ... COMMENT） - 禁止授予
CREATE USER、GRANT OPTION、SHUTDOWN、FILE—— 这些与 DDL 无关，且极易被滥用 - 确认账号主机范围精确：用
'ci_runner'@'10.20.30.%'比'ci_runner'@'%'安全得多；Kubernetes 场景下建议绑定 Service CIDR 或 Pod 网段
为什么不能依赖 GRANT 后立刻生效？
MySQL 的权限变更不是实时广播的，已建立的连接不会自动刷新权限。CI/CD 中常见错误是：GRANT 执行完马上用同一个连接执行 DDL，结果报错 ERROR 1142 (42000): ALTER command denied。
- 必须让 CI runner 显式重连（例如在脚本末尾加
mysql -u ci_runner -p... -e "SELECT 1"触发新连接） - 不要依赖
FLUSH PRIVILEGES：它只对 mysql 系统库的直接修改有效，而GRANT语句本身已自动写入系统表并通知线程缓存 - 如果用 Flyway/Liquibase，确保其 JDBC URL 包含
useSSL=false&allowPublicKeyRetrieval=true（MySQL 8.0.28+ 默认拒绝不安全握手），否则可能连不上就卡死
用角色（ROLE）管理权限更可控
MySQL 8.0+ 原生支持角色，比逐条 GRANT 更适合 CI/CD 场景：
- 先建角色：
CREATE ROLE 'ddl_executor'; - 批量授权：
GRANT CREATE, ALTER, DROP ON `app_prod`.* TO 'ddl_executor'; - 把角色赋予 CI 账号：
GRANT 'ddl_executor' TO 'ci_runner'@'10.20.30.%'; - 激活角色：
SET DEFAULT ROLE 'ddl_executor' TO 'ci_runner'@'10.20.30.%'; - 后续权限调整只需改角色，无需触碰每个账号；审计时查
mysql.role_edges表即可追溯
DDL 脚本里藏着的权限陷阱
即使账号权限正确，脚本本身也可能触发隐性权限失败：
- 含
ENGINE=MyISAM的建表语句，在禁用 MyISAM 插件的实例上会报ERROR 1286 (42000): Unknown storage engine 'MyISAM'—— 不是权限问题，而是配置限制 - 使用
ALTER TABLE ... ALGORITHM=INSTANT时，MySQL 8.4.6 LTS 要求账号还具备SUPER权限（仅限原子 DDL 元操作），但普通ALTER不需要；建议统一用ALGORITHM=INPLACE避开此限制 - 字段注释含单引号未转义（如
COMMENT 'user's status'），会导致语法错误，看起来像权限不足，实为 SQL 解析失败 - 执行
COMMENT ON COLUMN（PostgreSQL 风格）会静默失败，MySQL 不识别该语法；必须用ALTER TABLE ... MODIFY COLUMN ... COMMENT 'xxx'
最易被忽略的一点：CI runner 的 MySQL 客户端版本要 ≥ 服务端版本。MySQL 8.4.6 的原子 DDL 元数据结构变更后，若用 8.0.x 的 mysql 命令行客户端执行含 DROP COLUMN 的脚本，可能因协议解析差异导致部分操作被跳过而不报错。
