开发人员需最小化运维权限：仅限PROCESS（查连接）、SHOW DATABASES（限业务库）、SELECT（精确到库表），禁用SUPER/RELOAD/SHUTDOWN/GRANT OPTION，并须验证实际生效范围。
开发人员需要哪些运维操作权限
开发人员在日常联调、问题排查时，确实需要少量运维类能力，但绝不是给个 PROCESS 或 SUPER 就完事。真实需求集中在三类：查当前连接（看谁卡住了）、查慢查询（定位SQL性能瓶颈）、查表结构或索引（确认字段类型或缺失索引）。这些操作本身不修改数据、不变更结构，但若权限配置过宽，就可能滑向高危操作。
常见错误是直接授 GRANT PROCESS, SHOW DATABASES ON *.*，结果开发能执行 KILL 连接、能看到所有库名（包括敏感系统库），甚至通过 SHOW VARIABLES 泄露配置信息。这不是最小化，是“最小化包装下的全量暴露”。
用 GRANT 显式授予有限状态类权限
MySQL 8.0+ 支持细粒度的状态类权限，必须逐条显式授予，不能靠 ALL PRIVILEGES 带出来。以下权限组合已验证可用于开发人员日常排障，且无副作用：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
PROCESS：仅允许查看SHOW PROCESSLIST，但无法执行KILL（KILL需额外SUPER或CONNECTION_ADMIN） -
SHOW DATABASES：只显示有权限访问的库名（配合后续库级授权后，只会看到app_db这类业务库，不会列出mysql或information_schema） -
SELECT权限需精确到具体库表，例如：GRANT SELECT ON `app_db`.`users` TO 'dev_user'@'192.168.5.%' - 如需查慢日志，必须开启
slow_query_log并授SELECT权限给mysql.slow_log表（注意：该表默认关闭，且需LOG_ADMIN才能启用日志）
必须禁用的高危权限与隐式风险
开发账号一旦带上这些权限，就等于开了后门：
-
SUPER：可绕过所有限制，包括修改全局变量、终止任意连接、加载动态库——开发完全不需要 -
RELOAD：能执行FLUSH PRIVILEGES、FLUSH LOGS，影响实例稳定性 -
SHUTDOWN：直接关库，误点即中断服务 -
GRANT OPTION：允许开发再授予权限，形成失控扩散链 - 漏掉
REVOKE SELECT ON information_schema.*：即使没给SHOW DATABASES，开发仍可通过SELECT * FROM information_schema.tables WHERE table_schema = 'app_db'枚举所有表结构
权限验证不能只看 SHOW GRANTS
SHOW GRANTS FOR 'dev_user'@'192.168.5.%' 只显示显式授予的权限，不反映实际生效范围。真正要验证，得用该账号登录后实测：
- 执行
SHOW PROCESSLIST—— 应能看到自己和其他开发的连接，但看不到 DBA 的管理连接（若用了不同 host） - 执行
SHOW DATABASES—— 结果里只应出现被授权的业务库名，不含mysql、performance_schema等 - 执行
SELECT COUNT(*) FROM information_schema.columns—— 应报错Access denied，而非返回空结果（空结果说明权限已生效，只是没数据） - 尝试
KILL 123—— 必须失败，否则说明PROCESS被误配成SUPER
最易被忽略的是权限缓存：GRANT 或 REVOKE 后必须执行 FLUSH PRIVILEGES，否则新权限可能延迟生效，尤其在旧版本 MySQL 中更明显。
