最直接的防线是仅授予SELECT权限，禁用DELETE/UPDATE等写操作；配合sql_safe_updates=1、DROP/ALTER权限分级、最小化账号使用场景及定期检查连接配置，可有效防范误删误改。

只给 SELECT 权限，不给 DELETE/UPDATE 是最直接的防线

生产环境里，绝大多数日常查询（比如报表、BI取数、运维排查）根本不需要写权限。给账号仅授予 SELECT，就能彻底规避 DELETE FROM users; 这类无 WHERE 的误删。

实操建议：

• 用 CREATE USER 'reporter'@'%' IDENTIFIED BY 'xxx'; 新建专用只读账号
• 用 GRANT SELECT ON mydb.* TO 'reporter'@'%'; 授权，**不要用 GRANT ALL**
• 禁止对 mysql 系统库授权，避免绕过权限控制
• 应用连接池配置里显式指定该只读账号，而非复用 DBA 账号

sql_safe_updates=1 能拦住没加 WHERE 或 LIMIT 的危险操作

这个 MySQL 服务端参数不是权限机制，但对防止全表误删/误更新非常有效——它强制要求所有 UPDATE 和 DELETE 必须满足以下至少一项：

• 带 WHERE 子句且条件字段有索引（哪怕只是主键）
• 带 LIMIT（如 DELETE FROM logs LIMIT 1000;）

启用方式：

SET SESSION sql_safe_updates = 1;
-- 或在 my.cnf 中全局设置
[mysqld]
sql_safe_updates = 1

注意：它对 TRUNCATE 无效，TRUNCATE 本身也不走 WHERE，所以权限上仍需禁止该

用 DROP/ALTER 权限分级，避免“删库跑路”式操作

DBA 账号不该是唯一高权账号。应按操作粒度拆分权限：

• 日常维护账号：只给 RELOAD, PROCESS, SHOW DATABASES，**不给 DROP**
• 结构变更账号：单独授权 ALTER, CREATE, DROP，且限制在测试库或特定前缀的库（如 GRANT ALTER ON `app_%`.* TO 'ddl_user'@'%';）
• 备份账号：只需 SELECT + LOCK TABLES + REPLICATION CLIENT，绝不给写权限

特别注意：DROP DATABASE 权限无法按库限制，只要拥有该权限，就能删任意库。所以必须确保该权限只存在于 DBA 本地登录账号中，且禁用远程访问。

真正关键的不是权限多严，而是谁在什么场景下用了哪个账号

权限设计再细，如果开发在本地连生产库调试时用了高权账号，或者运维脚本硬编码了 root 密码，所有策略都形同虚设。

容易被忽略的点：

• 检查所有定时任务、ETL 脚本、监控采集程序使用的数据库账号，确认是否最小权限
• 应用配置中心里存的 DB 连接串，是否混用了开发/测试/生产账号
• MySQL 的 max_connections 和 wait_timeout 设置是否合理——连接长期空闲未释放，可能让误操作在会话中持续生效
• 权限变更后务必执行 FLUSH PRIVILEGES;，否则新规则不生效