mysql用户权限如何分配_mysql权限控制方法-mysql教程-PHP中文网

MySQL用户创建必须指定host，否则默认@'%'导致任意IP可连接；应按最小权限原则限定IP、库表、列级权限，并用Role统一管理。

mysql用户权限如何分配_mysql权限控制方法

用户创建必须带 host，否则等于放行所有 IP

MySQL 的 user@host 是一个完整身份标识，'app_user'@'localhost' 和 'app_user'@'%' 完全是两个账号。很多人执行 CREATE USER 'app_user' IDENTIFIED BY 'pwd';，没写 @'host'，结果 MySQL 默认补成 @'%' —— 这意味着该账号可从任意网络地址连接，是高危配置。

生产环境严禁用 @'%'，应明确限定 IP 段，如 @'192.168.50.%' 或具体应用服务器 IP
本地调试用 @'localhost'，注意它和 @'127.0.0.1' 不等价：前者走 Unix socket，后者走 TCP，权限不互通
若需多来源访问，宁可建多个账号（'app_user'@'192.168.50.10' + 'app_user'@'192.168.50.11'），也不用宽泛的通配符

授予权限别直接 ON .，先锁死数据库范围

全局权限（ON *.*）意味着能执行 DROP DATABASE、SHUTDOWN、CREATE USER 等管理操作，普通业务账号完全不需要。错误示例：GRANT ALL PRIVILEGES ON *.* TO 'app_user'@'%'; —— 这等于把数据库当裸机交出去。

开发/应用账号只给库级最小集：GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO 'app_user'@'192.168.50.%';
绝对禁止授予 DROP、ALTER、CREATE（除非 DBA 明确授权迁移任务）
监控类账号（如 Prometheus exporter）只需 SELECT ON performance_schema.* 和 PROCESS 全局权限，其他一概不要

列级权限不是“炫技”，而是敏感字段隔离刚需

当 HR 系统要给 BI 账号查员工表，但不能暴露 salary、id_card 字段时，靠应用层过滤或视图封装都不如原生列权限可靠——因为它是服务端强制拦截，连 SQL 解析阶段就拒绝非法列访问。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

语法很直白：GRANT SELECT(id, name, dept) ON hr.employees TO 'bi_reader'@'%';
注意：列权限只对 SELECT 和 UPDATE 有效，且必须配合表级 SELECT 权限才能生效（即先有表权限，再细化列）
一旦开了列权限，该用户执行 SELECT * FROM hr.employees; 会报错 ERROR 1142 (42000): SELECT command denied to user ... for column 'salary'，而不是静默过滤

MySQL 8.0+ 推荐用 Role 统一权限组，别硬写一堆 GRANT

当团队有 5 个开发、3 个测试、2 个运维都要访问同一套业务库时，逐个 GRANT 不仅易漏，更难回收。Role 就是为这种场景设计的“权限模板”。

先建角色：CREATE ROLE 'dev_team';，再批量授权：GRANT SELECT, INSERT, UPDATE ON myapp_db.* TO 'dev_team';
把人加进角色：GRANT 'dev_team' TO 'dev1'@'192.168.50.%', 'dev2'@'192.168.50.%';
新成员入职？只需 GRANT 'dev_team' TO 'dev3'@'...';；离职？REVOKE 'dev_team' FROM 'dev2'@'...';，干净利落
别忘了启用角色：SET DEFAULT ROLE 'dev_team' TO 'dev1'@'192.168.50.%';，否则登录后权限不自动生效

最常被忽略的一点：权限变更后无需 FLUSH PRIVILEGES —— 只要不用 INSERT/UPDATE 直接改 mysql.user 表，所有 CREATE USER、GRANT、ALTER USER 都实时生效。手抖敲了 FLUSH PRIVILEGES 不会报错，但纯属多余，还可能掩盖你其实没成功执行 GRANT 的事实。