应为每个应用创建最小权限专用用户,按需授予 SELECT、INSERT 等具体权限,禁用高危操作并定期审计。

要限制 MySQL 用户只能执行特定的 SQL 操作(比如只允许 SELECT,禁止 INSERT/UPDATE/DELETE),核心方法是通过 ** 精细化的权限控制 **,而不是靠应用层过滤或 SQL 解析——后者不可靠且易绕过。
创建最小权限专用用户
不要复用高权限账号(如 root 或管理员账号)。应为每个应用 / 场景单独建用户,并只授予必要权限:
- 只读需求:仅授权
SELECT权限到指定数据库或表 - 写入限制:若需写入,可只授
INSERT(不给UPDATE/DELETE),或进一步限定到某几张表 - 避免使用
GRANT ALL PRIVILEGES,哪怕在测试环境也应养成最小权限习惯
按库、按表精确授权
MySQL 支持多层级权限(全局 → 数据库 → 表 → 列),推荐按需下放:
-- 只允许 user_ro 对 db_app 的所有表执行 SELECT GRANT SELECT ON db_app.* TO 'user_ro'@'192.168.1.%'; -- 只允许 user_log 对 db_app.log_table 执行 INSERT(常用于日志写入)GRANT INSERT ON db_app.log_table TO 'user_log'@'%';
-- 刷新权限使生效 FLUSH PRIVILEGES;
注意:REVOKE 可撤销已有权限,例如 REVOKE UPDATE, DELETE ON db_app.* FROM 'user_ro'@'%';
禁用高危操作(补充防护)
权限控制是主防线,但可叠加以下配置增强安全性:
- 在
my.cnf中设置sql_safe_updates = 1,防止没有 WHERE 的UPDATE/DELETE(对已授权用户生效) - 禁用本地文件操作:启动时加
--secure-file-priv=NULL,阻止LOAD DATA INFILE/SELECT …… INTO OUTFILE - 避免开放
PROCESS、SUPER、FILE等管理类权限,除非绝对必要
验证与持续维护
授权后务必验证实际行为是否符合预期:
- 用新用户登录,尝试执行非授权语句(如
DELETE FROM t1),确认报错ERROR 1142 (42000): DELETE command denied - 定期审计用户权限:
SHOW GRANTS FOR 'username'@'host'; - 删除不再使用的账号:
DROP USER 'old_user'@'%';
权限不是设一次就一劳永逸,需随业务变化动态调整。






























