mysql如何配置用户的读写权限_mysql权限设计方案

来源：这里教程网时间：2026-02-28 20:50:40 作者：

如何用

GRANT

为用户分配最小必要读写权限

直接给

SELECT

、

INSERT

、

UPDATE

、

DELETE

四个权限，比给

ALL PRIVILEGES

安全得多，也更符合实际业务需求。

常见错误是把权限赋给

'user'@'%'

却忘了只允许从特定网段连入，结果暴露在公网；或者用

GRANT ... ON *.*

给了跨库权限，而应用其实只操作一个库。

按库授权：用
GRANT SELECT, INSERT, UPDATE, DELETE ON `app_db`.* TO 'app_user'@'192.168.10.%'
避免通配符主机：不用
'app_user'@'%'
，改用具体 IP 段或内网 DNS 名（如
'app_user'@'web-server-01'
）执行后必须跟
FLUSH PRIVILEGES
（仅在直接修改
mysql.user
表时才需要；用
GRANT
通常自动生效）

为什么不能跳过

CREATE

和

DROP

权限就认为“只读”安全

表面看只给了

SELECT

就是只读，但若用户还能创建临时表、视图或函数，就可能绕过限制——比如用

CREATE VIEW

包装敏感字段，再通过

SELECT

间接读取；或用

CREATE TEMPORARY TABLE

缓存并重写数据逻辑。

真正只读场景下，应显式拒绝高危操作：

不授予
CREATE
、
DROP
、
ALTER
、
INDEX
、
CREATE VIEW
、
SHOW VIEW
检查是否残留旧权限：
SHOW GRANTS FOR 'report_user'@'localhost'
若用 MySQL 8.0+，可考虑角色（
CREATE ROLE
）统一管理只读策略，避免逐个用户重复配置

REPLICATION SLAVE

权限不是给应用用户的，而是给从库同步用的

很多团队误把主从同步账号当成普通应用账号复用，导致应用意外具备读取 binlog 的能力，存在数据泄露和被注入风险。

正确做法是严格分离账号用途：

主从复制专用账号：只赋予
REPLICATION SLAVE
+
REPLICATION CLIENT
，主机限定为从库 IP 应用读写账号：仅限业务库的 DML 权限，禁止任何 replication 相关权限 监控账号（如 Prometheus）：只需
PROCESS
、
REPLICATION CLIENT
、
SELECT
on
performance_schema
，不碰业务表

MySQL 8.0 的

password_history

和

password_reuse_interval

对权限管控的实际影响

权限本身不控制密码策略，但弱密码会让已有权限的账号更容易被爆破或冒用。MySQL 8.0 内置的密码历史机制能降低凭证复用风险，属于权限体系的必要补足。

配置示例（在

mysql.user

表或

CREATE USER

时设置）：

CREATE USER 'app_user'@'192.168.10.%' 
IDENTIFIED WITH 'caching_sha2_password' 
BY 'StrongPass!2024' 
PASSWORD HISTORY 5 
PASSWORD REUSE INTERVAL 365 DAY;

注意：