只给 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;，否则新规则不生效
