共享账号天然不安全，因其共用同一身份导致无法审计操作者、密码泄露无追溯、权限变更影响全体、锁定即全局中断；必须按人/服务建独立账号并用mysql 8.0+角色隔离职责，禁用with grant option，通过流程卡点杜绝复用。

共享账号是MySQL权限失控的头号诱因，必须禁止——没有例外，没有“临时用一下”。

为什么共享账号天然不安全

MySQL的权限模型基于 'user'@'host' 组合，但共享账号（如 'dev'@'%'）让所有使用者共用同一身份：

• 无法区分谁执行了 DROP TABLE，审计日志只显示“dev”而非张三或李四
• 密码泄露后，攻击者直接获得该账号全部权限，且无痕迹可追溯具体责任人
• 权限变更（如加 ALTER）影响所有人，有人需要、有人不需要，最终变成“全有全无”
• 账号被锁定时，所有依赖它的服务同时中断，故障面被人为放大

替代方案：按人/按服务建独立账号

不是“少建几个”，而是“每人/每服务一个”：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 开发人员：用 'zhangsan'@'192.168.5.10'，只授 SELECT, INSERT, UPDATE 到对应测试库，禁用 DROP 和 CREATE
• CI/CD流水线：用 'jenkins_app'@'10.20.30.40'，仅授权 UPDATE 和 INSERT 到 deploy_log 表，不给库级权限
• 监控脚本：用 'monitor'@'192.168.100.5'，只开 PROCESS 和 SELECT on performance_schema，其他全关
• 离职/转岗人员：立刻执行 DROP USER 'lisi'@'%';，不要“先留着”

MySQL 8.0+ 必须用 ROLE 隔离职责，而非复用账号

角色不是“锦上添花”，是解决共享本质问题的唯一路径：

• 先建角色：CREATE ROLE 'app_writer', 'report_reader';
• 角色只授最小权限：GRANT INSERT, UPDATE ON app_db.orders TO 'app_writer';（绝不写 ON *.*）
• 再把角色分给人：GRANT 'app_writer' TO 'zhangsan'@'192.168.5.10';
• 权限变更时，只动角色，不动人；换人时，只改 GRANT，不改密码或权限逻辑
• 关键：禁用 WITH GRANT OPTION，防止角色权限被二次扩散

最容易被忽略的落地细节

很多团队建了独立账号和角色，但很快又退回到共享模式，问题往往出在三个地方：

• 应用配置里硬编码了账号密码，导致“换人就得改代码”，自然倾向复用旧账号
• 没清理历史遗留账号，SELECT user, host FROM mysql.user; 一查发现二十多个 'dev'@'%' 还活着
• 误以为 FLUSH PRIVILEGES 是万能刷新键——其实 GRANT/DROP USER 后根本不用它，徒增误操作风险

真正管住共享，靠的是流程卡点（比如上线前自动扫描 mysql.user 表中是否存在 @'%' 的非管理账号），而不是靠人自觉。