MySQL开发账号严禁DROP/ALTER权限，仅授SELECT/INSERT/UPDATE/DELETE；生产账号禁用FILE/PROCESS；多环境须用数据库名前缀隔离；从库账号须专用且限定IP。
MySQL开发账号不能有DROP或ALTER权限
开发环境不是沙盒，一旦误删表或改错结构，可能直接拖垮联调流程。生产权限模型必须从开发阶段就卡死高危操作。
实操建议：
- 创建开发账号时，只显式授予
SELECT、INSERT、UPDATE、DELETE，**绝对不执行**GRANT ALL PRIVILEGES - 用
SHOW GRANTS FOR 'dev_user'@'%'确认实际权限，注意USAGE和GRANT OPTION也得禁掉 - 如果要用
CREATE TABLE（比如跑Flyway迁移），单独授权，但限制在dev_%前缀的数据库，例如：GRANT CREATE ON `dev_%`.* TO 'dev_user'@'%' - 避免用
%通配符绑定主机，开发账号尽量限定为'dev_user'@'192.168.10.%'这类内网段
生产账号必须禁用FILE和PROCESS权限
这两个权限是MySQL提权链的关键跳板——FILE能读写服务器文件系统，PROCESS可看到其他连接的明文SQL（含密码）。哪怕只是只读账号，也不该有。
常见错误现象：
- DBA用
mysqldump备份时顺手给备份账号加了FILE，结果被攻破后攻击者导出/etc/passwd - 监控脚本依赖
SHOW PROCESSLIST，直接授了PROCESS，导致敏感SQL泄露
正确做法：
- 用
SELECT * FROM performance_schema.threads替代SHOW PROCESSLIST（需SELECT权限） - 备份走物理拷贝（xtrabackup）或主库专用只读账号+
SELECT+LOCK TABLES，绕开FILE - 检查已有账号：
SELECT User,Host,File_priv,Process_priv FROM mysql.user WHERE File_priv='Y' OR Process_priv='Y'
不同环境用不同数据库名前缀，别靠账号隔离
只靠账号权限控制多环境，等于把门锁交给每个人自己保管。真实场景里，开发连错库、运维切错实例太常见。
使用场景：
- 本地开发：数据库名统一用
dev_*（如dev_order） - 测试环境：用
test_* - 生产环境：无前缀（
order），且禁止任何非生产账号访问该命名空间
参数差异与影响：
- 应用配置里
database字段要随环境变量切换，而不是写死；否则CI/CD自动部署时容易串库 - Navicat等客户端默认记住最近连接，开发人员双击连上生产库后，随手执行
DROP TABLE user——这种事真发生过 - 用
init_connect设置会话级sql_mode时，注意不同前缀库可能需要不同严格度，别全局一刀切
REPLICATION SLAVE权限只给从库账号，且仅限复制专用用户
主从同步不是功能需求，是架构底座。给错账号权限，轻则同步中断，重则从库被当跳板反向写入主库。
容易踩的坑：
- 把主库备份账号和从库复制账号设成同一个，结果备份脚本里混进了
CHANGE MASTER TO命令，触发意外交互 - 从库账号有
REPLICATION CLIENT但没REPLICATION SLAVE，START SLAVE报错ERROR 1217 (HY000): Cannot add or update a child row，其实跟外键无关，是权限不足 - 用
mysqlbinlog --read-from-remote-server做日志分析时，误用复制账号，暴露BINLOG内容到公网
实操建议：
- 从库账号命名带标识，如
repl_user，主机限定为从库IP：GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.20.5' - 主库上定期查
SELECT user,host,ssl_type FROM mysql.user WHERE Repl_slave_priv='Y'，确保只有预期账号开启 - 从库启动后立刻执行
STOP SLAVE; SET GLOBAL read_only=ON;，防止人为误写
权限不是越细越好，而是要让每个账号刚好够用、且只能干它该干的事。最麻烦的从来不是配错一条GRANT，而是上线后发现某个“临时调试账号”还开着GRANT OPTION，而没人记得当初为什么留着它。
