MySQL 权限管理遵循最小权限原则,通过 GRANT/REVOKE 按操作类型(如 SELECT、INSERT)和对象范围(全局、库、表、列级)精细授权,禁用 FILE、SUPER 等高危权限,并配套独立账号、强密码、审计日志等措施。

MySQL 的权限管理通过 GRANT 和 REVOKE 实现,不能直接“限制执行 SQL”,而是通过精细授予或回收具体权限,控制用户能做什么。核心思路是:** 最小权限原则 + 按需授权 + 对象级控制 **。
按操作类型细分权限(常用 DML/DQL 权限)
避免直接给 ALL PRIVILEGES,只授必要权限:
- 只读用户 :仅授予
SELECT(可限定到库、表甚至列)
例:GRANT SELECT ON mydb.users TO 'reporter'@'localhost'; - 数据录入员 :可加
INSERT,禁用UPDATE/DELETE/DROP
例:GRANT INSERT ON mydb.orders TO 'clerk'@'%'; - 运维脚本账号:如需清日志表,可单独授
DELETE权限,但不给DROP或ALTER
按对象范围控制权限粒度
权限可作用于不同层级,越细越安全:
- 全局级(
*.*):仅用于超级管理员,普通用户禁用 - 数据库级(
db_name.*):适合部门级应用账号 - 表级(
db_name.table_name):例如财务系统只允许查salary表 - 列级 (
SELECT(col1,col2)):敏感字段如身份证号、密码哈希可单独屏蔽
例:GRANT SELECT(id,name,email) ON hr.employees TO 'hr_read'@'10.0.1.%';
禁用高危权限与危险操作
以下权限默认不应授予普通用户:
-
FILE:可读写服务器文件系统 → 防止读取配置或写入 Webshell -
PROCESS/SUPER:可查看其他用户 SQL、杀连接、修改全局变量 -
SHUTDOWN/RELOAD:影响服务稳定性 -
CREATE USER/GRANT OPTION:禁止权限扩散 - 若业务真需执行
TRUNCATE或DROP,建议改用存储过程封装,并只授 EXECUTE 权限
配合账号策略与审计增强管控
权限只是基础,还需配套措施:
- 为每个应用 / 角色创建独立账号,不用共用 root 或 test 账号
- 设置强密码 + 密码过期策略(
ALTER USER …… PASSWORD EXPIRE) - 启用 MySQL 审计插件(如
audit_log)或开启 general_log(生产慎用)记录高危语句 - 定期检查权限分配:
SELECT user, host, privilege_type FROM information_schema.role_table_grants;(MySQL 8.0+)或用SHOW GRANTS FOR 'user'@'host';






























