ddl权限需明确授予create、alter、drop、index、references等细粒度权限，仅给前三者不等于完整ddl能力；必须按目标库（如app_prod.*）授权，禁用super等高危权限，并确保连接时指定数据库、host匹配且认证插件兼容。
DDL权限到底需要哪些具体操作权限
只给 CREATE、DROP、ALTER 这三个权限，不等于就拥有了完整 DDL 能力。实际部署中常遇到“建表失败”“加索引被拒”，往往是因为漏掉了配套权限。MySQL 的 DDL 操作依赖一组细粒度权限组合：
-
CREATE：建库、建表、建视图、建存储过程等（但不含索引） -
INDEX：必须单独授予，否则CREATE INDEX或ALTER TABLE ... ADD INDEX会报错ERROR 1142 (42000): INDEX command denied -
REFERENCES：外键约束依赖此权限，否则ALTER TABLE ... ADD FOREIGN KEY失败 -
EVENT和TRIGGER：如果部署脚本含定时任务或触发器，也得显式加上 -
SHOW VIEW：读取视图定义（SHOW CREATE VIEW）所需，CI/CD 工具校验时常用
注意：ALL PRIVILEGES 在全局（*.*）下包含全部，但生产环境严禁这么用；最小化原则下，应明确列出必需项。
为什么不能直接 GRANT ON *.* 给部署账号
全局授权 GRANT ... ON *.* 看似方便，但在自动化场景中极易引发越权和误操作风险：
- 部署账号可能意外执行
DROP DATABASE mysql或ALTER TABLE mysql.user—— 即使没主观恶意，脚本模板错误或变量未渲染也会触发 - 某些中间件（如 Flyway、Liquibase）默认扫描
INFORMATION_SCHEMA，若账号有SHOW DATABASES权限，就会暴露所有库名，违反最小可见性原则 - MySQL 8.0+ 默认启用
sql_require_primary_key=ON等安全变量，但这些不靠用户权限控制，而靠会话级设置；全局账号若未在连接串中指定init_command，可能导致建表失败却难以定位
正确做法是限定到目标库：例如部署只涉及 app_prod 库，就用 GRANT ... ON app_prod.* TO 'deployer'@'10.10.%.%'，并确保该账号无法访问 mysql、information_schema 等系统库。
自动化部署账号必须禁用的权限项
DDL 专属账号 ≠ 全能 DBA 账号。以下权限看似无关，实则构成安全隐患，必须显式排除：
-
SUPER：可修改全局变量（如关掉read_only）、杀连接、绕过 binlog 限制——CI/CD 流水线一旦被注入恶意 SQL，后果严重 -
REPLICATION CLIENT和REPLICATION SLAVE：除非部署本身管理主从切换，否则不应开放复制相关权限 -
FILE：允许读写服务器文件系统，SELECT ... INTO OUTFILE或LOAD DATA INFILE可能被用于数据导出或本地提权 -
PROCESS：能看到其他用户正在执行的 SQL，属于敏感信息泄露点，非监控账号无需此权限
验证方式很简单：用部署账号登录后执行 SHOW GRANTS;，输出里不该出现上述任意一项。如果已有账号被误授，用 REVOKE SUPER ON *.* FROM 'deployer'@'%'; 撤销即可。
权限生效后仍报错的三个典型原因
执行完 GRANT 并 FLUSH PRIVILEGES;，部署脚本还是提示权限不足？大概率卡在这几个地方：
- MySQL 8.0+ 默认认证插件是
caching_sha2_password，但部分旧版 JDBC 驱动或 shell 工具不兼容——创建账号时要显式指定IDENTIFIED WITH mysql_native_password BY 'xxx' - 客户端连接时未声明目标数据库，例如用
mysql -u deployer -p -e "CREATE TABLE t1(...)"，此时语句在NULLdatabase 下执行，而权限是按app_prod.*授予的，必然失败；应改为mysql -u deployer -p app_prod -e "CREATE TABLE t1(...)” - 账号 host 匹配失败：你授的是
'deployer'@'10.10.20.5'，但 CI 机器实际出口 IP 是10.10.20.6，或者 DNS 解析后变成主机名而非 IP —— 建议用'deployer'@'10.10.20.%'或'deployer'@'%'（配合防火墙限制源 IP 更稳妥）
最省事的排查命令是：用部署账号登录后执行 SELECT USER(), CURRENT_USER();，前者是客户端声称的身份，后者是 MySQL 实际匹配到的账号——两者不一致，基本就是 host 匹配问题。
