MySQL（十六）：用户管理与权限控制

cui_ruicheng2026-06-30 14:41

目录

一、为什么需要用户管理

[1. 禁用单一超级管理员](#1. 禁用单一超级管理员)

[2. 多用户访问典型场景](#2. 多用户访问典型场景)

[二、MySQL 用户识别与创建](#二、MySQL 用户识别与创建)

[1. 用户信息存放](#1. 用户信息存放)

[2. 用户名与 Host 字段](#2. 用户名与 Host 字段)

[3. 当前登录用户](#3. 当前登录用户)

[4. 创建用户](#4. 创建用户)

三、修改与删除

[1. 修改用户密码](#1. 修改用户密码)

[2. 删除用户](#2. 删除用户)

四、数据库权限与用户授权

[1. 权限控制层级](#1. 权限控制层级)

[2. 常见权限分类](#2. 常见权限分类)

[3. 查看用户权限](#3. 查看用户权限)

[4. 用户授权](#4. 用户授权)

[4.1 授权操作案例](#4.1 授权操作案例)

[5. 权限回收](#5. 权限回收)

[5.1 回收操作案例](#5.1 回收操作案例)

五、综合案例

[1. 创建实验环境](#1. 创建实验环境)

[2. 多角色账户的创建与授权](#2. 多角色账户的创建与授权)

[3. 权限验证实验](#3. 权限验证实验)

总结

一、为什么需要用户管理

在单机开发或本地测试阶段，开发者通常习惯使用超级管理员账号（如 root）直连数据库。然而，在企业级生产系统或团队协作开发中，这种 "单一超级用户" 的访问模式有极高的安全隐患

1. 禁用单一超级管理员

MySQL 的 root 用户拥有绝对特权，包括但不限于创建/销毁数据库、修改全局配置、关闭数据库服务以及直接读写底层系统表空间。在生产环境中，将 root 权限暴露给所有访问者会引发以下重大风险：

  • 高危误操作：缺乏权限限制意味着任何连接者都可以执行 DROP DATABASE 或无 WHERE 条件的 DELETE/UPDATE 语句。一旦发生人为失误，整个生产环境将直接崩溃

  • 泄露风险：如果多个业务系统、开发人员、数据分析师共用一个 root 密码，只要其中任何一个客户端遭遇黑客攻击或发生配置泄露，整个数据库的全部控制权将悉数落入攻击者手中

  • 行为审计与追溯：当所有操作都挂在 root 账号下时，数据库审计日志将失去区分度。一旦发生恶意篡改或泄露事故，系统将无法精准定位到具体的责任主体或具体的微服务节点

2. 多用户访问典型场景

现代企业级架构中，访问数据库的主体多种多样，通常可以划分为以下两大类：

自动化程序/应用服务账号

  • 业务微服务集群：不同的微服务应当持有独立的数据库连接账号。订单服务通常只需要对订单表执行 SELECT/INSERT/UPDATE 的权限，而不应具备读取用户密码表或修改库存表结构的权限

  • 自动化脚本与大数据 ETL：定时任务、数据备份工具以及大数据抽取平台，其访问频次和操作边界各不相同。数据备份只需要全局只读锁权限，而无需任何写入和修改结构的功能

人工操作账号

  • 数据库管理员：负责全局维护、性能调优与架构扩容，持有高级管理特权

  • 后端开发与测试工程师：在日常排查问题或灰度发布时，需要读取线上或测试环境数据

  • 数据分析师：需要对海量历史流水进行聚合统计与报表分析，只需要特定报表表的读取权限

最小特权原则

为了应对上述复杂的访问诉求，信息安全领域提出了一个核心思想------最小特权原则

基于此原则构建的权限管理机制，其核心价值体现在以下三个维度：

  • 收敛攻击面：通过将用户的权限严格限制在特定的数据库、特定的表甚至特定的列上，即使该用户的凭证不幸泄露，受波及的损害范围也被死死锁在当前可控的边界内

  • 实现职责分离：确保不同岗位的人员和不同的程序各司其职。例如，开发人员无法直接修改生产环境表结构，只能通过特定的 DDL 变更平台审计后执行；常规分析师无法看到用户的明文手机号

  • 提供完整的审计链路：每一个连接、每一次查询、每一次数据变更都有明确的账号主体与之对应。配合数据库审计插件，能够清晰地追踪到 "谁、在什么时间、从哪个 IP、执行了什么 SQL"，从而满足诸如 GDPR、数据安全法以及行业内控的严苛合规要求

二、MySQL 用户识别与创建

在深入了解授权操作之前，必须首先掌握 MySQL 如何在底层定义和识别一个 "用户"。与操作系统或其他轻量级应用不同，MySQL 的用户身份呈现出双重绑定的物理特征

1. 用户信息存放

MySQL 实例的所有账户及全局全局权限数据，均持久化存储在系统数据库 mysql 的 user 表中

我们可以通过执行以下语句来查看当前实例中的核心用户信息：

sql 复制代码 
SELECT Host, User, authentication_string, plugin FROM mysql.user;

在该表中，有四个决定账户安全的核心字段：

  • User：账户的名称

  • Host：限定该账户允许从哪些 IP 地址或主机名连接数据库

  • authentication_string：经过加密算法处理后的密码哈希值，MySQL 绝不存储明文密码

  • plugin：该账户使用的认证插件（例如 MySQL 8.0 默认的 caching_sha2_password）

2. 用户名与 Host 字段

在 MySQL 中，一个合法的账户定义必须由用户名和主机名共同组成，格式为 'username'@'host'。缺少任何一部分，都无法完整表达一个独立的身份

Host 字段的解析规则

Host 字段是实现网络层访问控制的第一道防线，它支持以下几种配置模式：

  • 特定 IP 地址：例如 'appsrv'@'192.168.1.50'，表示该账户只能通过 192.168.1.50 这台服务器发起连接，从其他任何 IP 访问均会被拒绝

  • 本地环回地址：例如 'dbadmin'@'localhost' 或 'dbadmin'@'127.0.0.1'。在物理表现上，localhost 会触发 Unix Socket 本地套接字通信，而 127.0.0.1 则走 TCP/IP 本地回环协议

  • 通配符掩码：例如 'report_user'@'192.168.1.%'，允许 192.168.1.0/24 网段内的所有主机连接

  • 全通配符：'global_user'@'%'，允许从任意 IP 地址发起连接。在生产环境中，除极少数特定的只读网关外，通常严禁对高权限账户开放 % 限制

3. 当前登录用户

在排查连接问题或确认当前会话的生效权限时，可以使用内置函数进行探查。特别需要注意以下两个函数的细微区别：

sql 复制代码 
SELECT USER(), CURRENT_USER();

  • USER()：返回客户端连接时实际输入的 "用户名@客户端真实IP"

  • CURRENT_USER()：返回当前会话经过 MySQL 身份认证后，最终匹配并落入到 mysql.user 表中的那条"用户名@主机规则"。（例如输入 root@192.168.1.55 登录，若命中通配符，CURRENT_USER() 返回的可能是 root@'%'）

4. 创建用户

在现代 MySQL 版本中，严禁通过直接向 mysql.user 表执行 INSERT 语句来创建账户，必须使用标准的 DDL 指令 CREATE USER

基本语法

sql 复制代码 
CREATE USER 'username'@'host' IDENTIFIED BY 'password';

使用案例

根据不同的网络拓扑需求，创建不同生命周期的基础用户：

sql 复制代码 
-- 案例 1：创建仅允许本地连接的开发测试用户
CREATE USER 'dev_local'@'localhost' IDENTIFIED BY 'Secure_Pass123!';

-- 案例 2：创建允许特定内网应用网段访问的微服务节点用户
CREATE USER 'order_service'@'10.0.2.%' IDENTIFIED BY 'Order_Srv_Prod#2026';

-- 案例 3：创建允许任意远程连接的数据报表只读用户（受网络策略保护）
CREATE USER 'bi_reporter'@'%' IDENTIFIED BY 'BI_Analysis_99x';

执行完毕后，新创建的账户仅具备最基础的 USAGE 权限（即只能登录并连接成功，无法看到或操作任何业务数据库）

三、修改与删除

账户建立后，由于人员变更、安全策略轮转或项目下线，需要对账户进行密码变更或销毁

1. 修改用户密码

密码修改通常由超级管理员发起，或者由用户在当前会话中自行维护。基于当前主流的架构标准，推荐采用 ALTER USER 语法

使用 ALTER USER 语句

sql 复制代码 
-- 修改指定远程开发用户的密码，并立即强制生效
ALTER USER 'dev_local'@'localhost' IDENTIFIED BY 'New_Crypto_Pass_2026#';

使用 SET PASSWORD 语句（会话级修改别名）

sql 复制代码 
-- 针对特定账户进行密码刷新
SET PASSWORD FOR 'order_service'@'10.0.2.%' = 'Brand_New_Pass_888';

-- 修改自己的密码
SET password=password('新的密码')

修改 root 密码的流程

修改高权限账户密码时，应顺便对认证插件进行显式指定，以防止客户端由于协议版本不一致引发连接中断：

sql 复制代码 
-- 修改 root 本地账户密码，并显式指定使用高性能的安全加密插件
ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password 
BY 'Root_Ultra_Secure_999!';

-- 刷新特权系统字典表，确保内存中的权限控制 hash 缓存与磁盘完全同步
FLUSH PRIVILEGES;

2. 删除用户

当某个微服务下线或员工离职时，必须及时清理对应的数据库账户

基本语法

sql 复制代码 
DROP USER 'username'@'host';

账户清除案例与安全注意事项

sql 复制代码 
-- 级联删除指定账户
DROP USER IF EXISTS 'bi_reporter'@'%';

账户销毁的陷阱与规范

有些开发者习惯通过 DELETE FROM mysql.user WHERE User='...' 方式来抹除账户。这是生产环境中的严重违规操作

  • 原因：MySQL 的权限体系是分布式存放在 mysql.user（全局级）、mysql.db（数据库级）、mysql.tables_priv（表级）以及 mysql.columns_priv（列级）等多个维度的系统表中的

  • 后果 ：使用 DELETE 语句只会擦除 mysql.user 表中的登录凭证，而该用户在其他底层子表中持有的权限记录将全部变成孤儿数据。未来如果创建了同名的全新用户，该新用户会自动继承这些残留的越权权限，从而引发重大安全漏洞

  • 规范：必须统一使用 DROP USER 语句。该指令在底层会自动执行级联清理，将所有子表里涉及该 'username'@'host' 的权限行一次性全部彻底删除

四、数据库权限与用户授权

在完成账户的创建与基础维护后，接下来的核心任务是为账户赋予特定的操作特权。MySQL 拥有一套严密的权限控制体系，其权限的授予与检查是通过一个层级递进的漏斗形矩阵来实现的

1. 权限控制层级

MySQL 的权限检查从上到下共分为四个层级。当客户端执行一条 SQL 语句时，权限验证引擎会按照从全局到列级的顺序依次匹配，一旦在高级别命中允许规则，则不再向下检查；若全盘未命中，则拒绝访问

全局层级

  • 控制范围：适用于当前 MySQL 实例下的所有数据库、所有表以及所有系统管理操作

  • 物理存储：直接记录在 mysql.user 表中

  • 影响：授予全局权限意味着用户对整个数据库集群拥有最高控制权

数据库层级

  • 控制范围：仅适用于指定的某个具体数据库（Schema）下的所有物理对象

  • 物理存储：记录在 mysql.db 表中

数据表层级

  • 控制范围：仅适用于指定数据库内的某张特定数据表或视图。

  • 物理存储：记录在 mysql.tables_priv 表中

列层级

  • 控制范围：最精细的控制粒度，能够精确控制用户是否能读写某张表内的某一个或某几个特定字段

  • 物理存储：记录在 mysql.columns_priv 表中

2. 常见权限分类

MySQL 的权限多达数十种，在日常研发与运维管理中，通常可以将其收拢并划分为以下三类：

权限大类 常见权限关键字 物理操作行为描述
数据操作权限（DML） SELECT INSERT UPDATE DELETE 允许读取行记录 允许写入新行 允许修改现有行数据 允许删除物理行
结构操作权限（DDL） CREATE DROP ALTER INDEX 允许创建新数据库或新表 允许销毁数据库或表 允许修改表结构（加减列、改类型） 允许创建或删除索引
系统管理权限（DCL） GRANT OPTION RELOAD SHUTDOWN 允许该用户将自身拥有的权限转授给他人 允许执行 FLUSH 等刷新缓存指令 允许关闭数据库服务

关于 ALL PRIVILEGES

ALL PRIVILEGES 代表除了 GRANT OPTION 之外的所有可用特权。需要特别注意的是，在不同的层级授予 ALL PRIVILEGES 其意义完全不同：在全局层级代表超级管理员权限，而在数据库层级则仅代表对该特定库的完全控制权

3. 查看用户权限

在实施变更前，审计现有权限是标准的操作规范。使用 SHOW GRANTS 语句可以逆向解析出当前账户持有的完整授权路径

sql 复制代码 
-- 语法结构
SHOW GRANTS FOR 'username'@'host';

-- 查看微服务账号的当前特权
SHOW GRANTS FOR 'order_service'@'10.0.2.%';

系统返回示例： GRANT USAGE ON *.* TO 'order_service'@'10.0.2.%' (注：USAGE 表示仅有连接权限，*.* 表示全局层级无任何特权)

4. 用户授权

在较老的 MySQL 版本中，GRANT 语句具备隐式创建账户的功能（即如果账户不存在，授权时会自动创建）。在现代生产环境中，这一行为已被完全禁止。 必须严格遵循 "先使用 CREATE USER 创建账户，再使用 GRANT 授权" 的流程

基础语法

sql 复制代码 
GRANT 权限列表 ON 作用层级 TO 'username'@'host';

4.1 授权操作案例

数据库层级授权

将 crm_prod 数据库下所有表的读写权限赋予微服务账户，但不给 DDL（建表/删表）权限：

sql 复制代码 
GRANT SELECT, INSERT, UPDATE, DELETE ON crm_prod.* TO 'order_service'@'10.0.2.%';

数据表层级授权

只允许第三方对账系统读取特定的结算流水表（t_settlement_flow）：

sql 复制代码 
GRANT SELECT ON crm_prod.t_settlement_flow TO 'third_audit_user'@'%';

列层级授权

数据分析师需要读取员工表（t_employee），但出于安全合规考虑，严禁其查看薪资字段。我们可以只下发非敏感列的读取权限：

sql 复制代码 
GRANT SELECT(emp_id, department, nickname) ON crm_prod.t_employee 
    TO 'bi_analyst'@'%';

全库级授权

创建一个拥有某独立业务库全部控制权，且允许其向下级继续授权的管理员账户：

sql 复制代码 
GRANT ALL PRIVILEGES ON crm_prod.* TO 'crm_admin'@'%' WITH GRANT OPTION;

5. 权限回收

当项目阶段性结束，或者系统安全策略收紧时，需要通过 REVOKE 语句回收账户已持有的特权

基础语法

sql 复制代码 
REVOKE 权限列表 ON 作用层级 FROM 'username'@'host';

5.1 回收操作案例

回收指定权限

发现某微服务账号持有 DELETE 权限存在安全风险，对其单独执行定向收回：

sql 复制代码 
REVOKE DELETE ON crm_prod.* FROM 'order_service'@'10.0.2.%';

清空全部特权

对即将停止维护的分析师账户回收所有权限：

sql 复制代码 
REVOKE ALL PRIVILEGES, GRANT OPTION ON *.* FROM 'bi_analyst'@'%';

权限回收规则

执行 REVOKE 时，指定的层级必须与当初执行 GRANT 时的层级严格保持对齐

例如，当初通过 GRANT SELECT ON crm_prod.* 赋予了用户整个库的读取权限，如果你尝试执行 REVOKE SELECT ON crm_prod.t_user FROM ...（企图只收回其中一张表的权限），MySQL 将会直接报错拒绝。这是因为底层权限链是以记录行为单位管理的，无法在不拆分物理行的情况下实施跨层级部分核销

五、综合案例

为了将前文所述的用户管理与权限控制理论转化为实践，本节将模拟一个金融业务场景------初始化金融核心数据库 finance_prod，并通过严格的最小特权原则为开发人员、数据分析师以及业务线管理员定制差异化的访问账户，最后进行全链路的权限防御验证

1. 创建实验环境

首先，使用超级管理员账户登录数据库，创建实验所需的数据库及数据表，并注入初始流水数据

sql 复制代码 
-- 1. 创建核心金融数据库
CREATE DATABASE finance_prod CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
USE finance_prod;

-- 2. 创建交易流水表
CREATE TABLE t_transactions (
    txn_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    account_no VARCHAR(30) NOT NULL,
    amount DECIMAL(15, 2) NOT NULL,
    txn_type VARCHAR(10) NOT NULL,
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

-- 3. 创建系统审计日志表
CREATE TABLE t_audit_log (
    log_id INT PRIMARY KEY AUTO_INCREMENT,
    operator VARCHAR(50) NOT NULL,
    action_type VARCHAR(20) NOT NULL,
    log_time DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

-- 4. 写入初始数据
INSERT INTO t_transactions (account_no, amount, txn_type) VALUES 
('62250001', 50000.00, 'DEPOSIT'),
('62250002', -1200.50, 'WITHDRAW');

2. 多角色账户的创建与授权

根据企业网络拓扑结构与岗位职责划分，我们需要在 mysql 实例中隔离创建三个独立的账户

1 创建开发团队账户（fin_dev）

安全策略：开发人员允许在指定的办公网段（192.168.10.0/24）连接数据库。他们需要拥有对 finance_prod 库进行日常数据读写（DML）以及结构微调（DDL）的权限，但严禁其删除整个数据库

sql 复制代码 
-- 创建账户
CREATE USER 'fin_dev'@'192.168.10.%' IDENTIFIED BY 'Dev_Project_Secure_2026#';

-- 授予 DML 与基础 DDL 权限（排除 DROP 权限）
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX ON finance_prod.* TO 'fin_dev'@'192.168.10.%';

2 创建数据分析师/只读账户（fin_reader）

安全策略 ：分析师通常通过报表系统或 BI 工具远程连接，由于访问链路较杂，设置其 Host 为通配符 %。其操作边界被限制在仅允许执行读取操作，严禁任何形式的数据污染与结构变更

sql 复制代码 
-- 创建账户
CREATE USER 'fin_reader'@'%' IDENTIFIED BY 'Reader_Analytical';

-- 仅授予全局指定库的 SELECT 权限
GRANT SELECT ON finance_prod.* TO 'fin_reader'@'%';

3 创建业务线本地管理员账户（fin_admin）

安全策略：该账户拥有对 finance_prod 数据库的绝对控制权，且允许其向后续加入的下属转授权限。为确保安全，该高权限账户被限制只能在特定的 IP（192.168.10.50）上发起登录

sql 复制代码 
-- 创建账户
CREATE USER 'fin_admin'@'192.168.10.50' IDENTIFIED BY 'Admin_High_Authority_999#';

-- 授予该库的完全控制权并开启特权转授功能
GRANT ALL PRIVILEGES ON finance_prod.* TO 'fin_admin'@'192.168.10.50' WITH GRANT OPTION;

-- 刷新缓存确保授权即时生效
FLUSH PRIVILEGES;

3. 权限验证实验

账户授权完成后，我们分别切换到不同的会话终端，验证权限效果

验证只读账户 fin_reader

使用 fin_reader 账户登录，依次执行读取和写入指令：

sql 复制代码 
-- 会话切换至 fin_reader
USE finance_prod;

-- 1. 尝试执行合规读取
SELECT * FROM t_transactions;
-- 结果：执行成功，正常返回 2 条流水记录。

-- 2. 尝试修改或插入数据
INSERT INTO t_transactions (account_no, amount, txn_type) VALUES ('62250003', 100.00, 'DEPOSIT');
-- 结果：执行失败

验证开发账户 fin_dev

使用 fin_dev 账户从 192.168.10.15 客户端连接，验证其 DDL 与高危越权阻断：

sql 复制代码 
-- 会话切换至 fin_dev
USE finance_prod;

-- 1. 尝试修改表结构（追加字段）
ALTER TABLE t_transactions ADD COLUMN remark VARCHAR(255);
-- 结果：执行成功。Query OK, 0 rows affected.

-- 2. 尝试执行高危越权操作
DROP DATABASE finance_prod;
-- 结果：执行失败。权限引擎直接阻断：

验证管理员账户 fin_admin 的转授特权

使用 fin_admin 从（192.168.10.50）登录，模拟为新员工分配只读权限：

sql 复制代码 
-- 会话切换至 fin_admin
USE finance_prod;

-- 1. 创建一个新加入的审计员账户
CREATE USER 'fin_auditor'@'%' IDENTIFIED BY 'Audit_Pass_123';

-- 2. 将自身持有的 finance_prod 库的只读权限转出去
GRANT SELECT ON finance_prod.* TO 'fin_auditor'@'%';
-- 结果：执行成功。由于持有 WITH GRANT OPTION，该操作被允许

总结

综上所述，我们学习了 MySQL 的用户管理与权限控制机制，掌握了用户的创建、删除、密码修改以及权限授予、查看和回收等常见操作。同时，通过多个案例进一步理解了 MySQL 如何通过权限系统保证不同用户只能访问各自被授权的数据库资源

可以发现，数据库不仅需要具备高效的数据存储和查询能力，还需要完善的安全管理机制。合理地规划用户角色和权限范围，不仅能够保护数据安全，也能够降低误操作带来的风险，这也是实际项目部署过程中不可或缺的一部分

至此，我们已经完成了 MySQL 大部分管理与使用层面的内容。不过，到目前为止，我们的所有操作都还是在 MySQL 命令行中完成的，而实际开发中，应用程序往往需要通过代码与数据库建立连接，完成数据的增删改查等操作

因此，在下一篇中，我们将正式学习如何在 C/C++ 程序中连接 MySQL 数据库，介绍 MySQL Connector 的基本使用流程，并实现代码层面的数据库访问，为后续开发数据库驱动的网络应用打下基础

热门推荐
012026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？022026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？032026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf04Trae国际版与国内版深度测评：AI原生IDE的双生花05飞书长连接_事件订阅（接收消息，审批任务状态变更）06Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析07【AI】2026 年具身智能模型和世界模型总结08GitHub 镜像站点092026年AI架构实战：彻底解决OpenAI接口超时与封号，Python调用GPT-5.2/Sora2企业级架构详解（附源码+压测报告）102026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？