MySQL用户如何更改_MySQL用户权限修改与账户管理教程

看不見的法師

发布时间：2025-09-02 12:48:01

1080人浏览过

来源于php中文网

原创

MySQL用户权限管理需遵循最小权限原则，通过GRANT授予权限、REVOKE撤销权限、ALTER USER修改密码或认证方式，CREATE USER创建用户，并结合FLUSH PRIVILEGES刷新权限；权限可细化至全局、数据库、表或列级别，生产环境中应限制主机访问、使用强密码、定期审计，避免滥用ALL PRIVILEGES、root账户直连和通配符主机名，确保账户安全可控。

mysql用户如何更改_mysql用户权限修改与账户管理教程

MySQL用户权限的修改和账户管理，说白了，就是如何给数据库里的“人”分配他们能干什么、不能干什么，以及管理他们的“身份证明”和“居住地”。这活儿在我看来，是数据库管理里最基础也最容易出岔子的一个环节，但又至关重要，直接关系到数据库的安全性和应用的正常运行。核心的思路就是“按需授权”和“最小权限原则”，确保每个用户都只有完成其工作所必需的权限，不多不少。

解决方案

要更改MySQL用户的权限，或者管理他们的账户信息，我们主要依赖几个核心的SQL命令：

GRANT

用于授予权限，

REVOKE

用于撤销权限，以及

ALTER USER

用于修改用户本身的属性，比如密码或认证方式。

当你需要给一个用户赋予特定操作的权力时，比如让一个应用用户能够查询某个数据库的表，你会用到

GRANT

语句。它的基本形式是

GRANT [权限类型] ON [数据库对象] TO '用户名'@'主机名' [IDENTIFIED BY '密码'] [WITH GRANT OPTION];

。举个例子，如果我想让

app_user

这个用户从

localhost

连接，并能对

mydatabase

数据库下的所有表进行

SELECT

、

INSERT

和

UPDATE

操作，命令会是这样：

GRANT SELECT, INSERT, UPDATE ON mydatabase.* TO 'app_user'@'localhost' IDENTIFIED BY 'your_strong_password';
FLUSH PRIVILEGES; -- 通常来说，GRANT和REVOKE会自动刷新权限，但显式执行有时能避免一些意想不到的情况，尤其是在旧版本或某些特定场景下。

这里的

mydatabase.*

表示

mydatabase

数据库下的所有对象。如果只针对特定表，比如

mydatabase.mytable

。

IDENTIFIED BY

部分是可选的，如果你是在创建新用户并同时授权，或者想修改现有用户的密码。

而当你想收回某个用户的权限时，

REVOKE

就派上用场了。它的语法和

GRANT

非常相似，只是把

GRANT

换成了

REVOKE

：

REVOKE [权限类型] ON [数据库对象] FROM '用户名'@'主机名';

。比如，要撤销

app_user

在

mydatabase

上的

INSERT

权限：

REVOKE INSERT ON mydatabase.* FROM 'app_user'@'localhost';
FLUSH PRIVILEGES;

至于账户本身的管理，比如修改密码或者认证插件，

ALTER USER

是首选。比如，修改

app_user

的密码：

ALTER USER 'app_user'@'localhost' IDENTIFIED BY 'new_strong_password';
FLUSH PRIVILEGES;

或者更改认证插件（比如从

mysql_native_password

到

caching_sha2_password

，这在MySQL 8.0之后很常见）：

ALTER USER 'app_user'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'new_strong_password';
FLUSH PRIVILEGES;

创建一个新用户则用

CREATE USER

：

CREATE USER 'new_user'@'%' IDENTIFIED BY 'another_strong_password';
-- 然后再用GRANT给这个新用户授权
GRANT SELECT ON mydatabase.some_table TO 'new_user'@'%';
FLUSH PRIVILEGES;

这里的

表示该用户可以从任何主机连接，但在生产环境中，我个人强烈建议限制为特定的IP地址或子网，以提高安全性。

如何为MySQL用户授予不同级别的操作权限？

为MySQL用户授予不同级别的操作权限，是实现精细化权限管理的关键。权限的粒度可以非常细，从全局（整个MySQL服务器）到特定数据库、特定表，甚至到特定表的特定列。这有点像公司里的职位分配，有些是高管，权限覆盖整个公司；有些是部门经理，只管自己部门；还有些是普通员工，只负责自己的具体任务。

全局权限 (Global Privileges) 这些权限作用于整个MySQL服务器，通常只授予数据库管理员或需要执行全局性操作的用户。例如，

CREATE USER

、

RELOAD

、

SHUTDOWN

等。授予全局权限的语法是

ON *.*

：

GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost' WITH GRANT OPTION;

WITH GRANT OPTION

允许这个用户把自己拥有的权限再授予其他用户，这在生产环境里要慎用，避免权限滥用。

数据库级权限 (Database Privileges) 这些权限作用于某个特定的数据库，通常是应用程序用户最常需要的权限级别。例如，

SELECT

、

INSERT

、

UPDATE

、

DELETE

、

CREATE

、

DROP

等。语法是

ON database_name.*

：

GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO 'app_user'@'192.168.1.100';

这里，

app_user

只能对

myapp_db

数据库中的所有表执行增删改查操作，对其他数据库则无权访问。

表级权限 (Table Privileges) 如果你的应用程序只需要访问某个数据库中的特定表，而不是整个数据库，那么表级权限就非常合适。语法是

ON database_name.table_name

：

GRANT SELECT ON myapp_db.users TO 'report_user'@'localhost';

这样，

report_user

只能查询

myapp_db

数据库中的

users

表，对其他表或数据库则没有权限。

列级权限 (Column Privileges) 这是最细粒度的权限，允许用户只对表的特定列进行操作。这在某些敏感数据场景下非常有用，比如一个用户只能更新员工表的

address

列，但不能查看

salary

列。语法是

ON database_name.table_name (column_name, ...)

：

GRANT UPDATE (address) ON myapp_db.employees TO 'hr_user'@'localhost';

注意，列级权限通常只支持

SELECT

、

INSERT

和

UPDATE

。

常用权限类型一览：

E酷购网络商城建站程序

一套傻瓜式的建站程序，由前台购物、后台管理、在线支付三部分组成介绍说明：1.注册与否均可购物（同类程序大多要求注册才能购物），方便了那些懒得注册的客户。降低用户使用门槛，自然可抓住更多潜在商机。2.会员等级和折扣功能。管理员可方便的为会员设置不同等级，不同等级的员会可享受不同的购物折扣。3.站内短信、留言发布，沟通无极限。会员和游客均可发送短信和留言。4.完美融合在线支付功能，无需编程、无需修改源

下载

```
SELECT
```
: 查询数据。
```
INSERT
```
: 插入数据。
```
UPDATE
```
: 修改数据。
```
DELETE
```
: 删除数据。
```
CREATE
```
: 创建数据库或表。
```
DROP
```
: 删除数据库或表。
```
ALTER
```
: 修改表结构。
```
INDEX
```
: 创建或删除索引。
```
CREATE VIEW
```
: 创建视图。
```
SHOW VIEW
```
: 查看视图。
```
ALL PRIVILEGES
```
: 授予所有权限（在指定对象上）。

选择合适的权限级别，并只授予必要的权限，这不仅是最佳实践，更是数据库安全的基础。过多或过宽的权限，就像给一个普通员工发了公司所有部门的钥匙，风险太高了。

MySQL用户权限如何撤销？账户密码或主机限制又该如何修改？

撤销MySQL用户权限，以及修改账户的密码或主机限制，是日常管理中非常常见的操作。有时候是项目需求变更，有时候是员工离职，或者只是单纯的安全策略更新。

撤销权限 (REVOKE) 撤销权限的命令是

REVOKE

，它的语法结构与

GRANT

几乎是镜像的。你需要明确撤销哪些权限，在哪个数据库对象上，以及是哪个用户。

REVOKE [权限类型] ON [数据库对象] FROM '用户名'@'主机名';

例如，如果之前给

app_user

在

myapp_db

数据库上授予了

INSERT

权限，现在想撤销：

REVOKE INSERT ON myapp_db.* FROM 'app_user'@'192.168.1.100';
FLUSH PRIVILEGES;

如果想撤销所有权限（但保留用户账户本身）：

REVOKE ALL PRIVILEGES ON myapp_db.* FROM 'app_user'@'192.168.1.100';
FLUSH PRIVILEGES;

这会撤销该用户在

myapp_db

上的所有数据库级权限。如果之前授予了全局权限，也需要用

REVOKE ALL PRIVILEGES ON *.*

来撤销。

修改账户密码 (ALTER USER) 修改用户密码是

ALTER USER

命令最常见的用途之一。这在定期密码轮换或密码泄露风险时非常重要。

ALTER USER '用户名'@'主机名' IDENTIFIED BY '新密码';
FLUSH PRIVILEGES;

例如，修改

app_user

的密码：

ALTER USER 'app_user'@'192.168.1.100' IDENTIFIED BY 'a_very_strong_new_password';
FLUSH PRIVILEGES;

需要注意的是，从MySQL 8.0开始，默认的认证插件是

caching_sha2_password

，如果你的应用或客户端不支持这个插件，你可能需要在创建或修改用户时指定旧的

mysql_native_password

插件：

ALTER USER 'app_user'@'192.168.1.100' IDENTIFIED WITH mysql_native_password BY 'a_very_strong_new_password';
FLUSH PRIVILEGES;

这其实是个兼容性问题，我个人在升级MySQL 8.0之后就遇到过几次，客户端连不上，排查半天才发现是认证插件的问题。所以，在生产环境做这类变更前，务必测试。

修改主机限制 MySQL的用户账户是由

用户名

和

主机名

（

'user'@'host'

）共同定义的。这意味着，你不能直接“修改”一个现有用户的主机名部分。如果你想改变一个用户允许连接的来源主机，通常的做法是：

创建一个新用户，使用相同的用户名但不同的主机名，并授予其相同的权限。
删除旧用户。

例如，如果

app_user

原先只能从

192.168.1.100

连接，现在想让它从

192.168.1.200

连接：

-- 1. 创建新用户（如果权限复杂，可以先查看旧用户的权限，再GRANT给新用户）
CREATE USER 'app_user'@'192.168.1.200' IDENTIFIED BY 'a_very_strong_password';
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO 'app_user'@'192.168.1.200';
FLUSH PRIVILEGES;

-- 2. 删除旧用户
DROP USER 'app_user'@'192.168.1.100';
FLUSH PRIVILEGES;

这种方式虽然看起来有点“笨”，但却是最直接且安全的方式。直接修改

mysql.user

表是不推荐的，因为那可能会破坏MySQL内部的用户管理机制。

管理MySQL用户权限时常见的误区与安全实践有哪些？

管理MySQL用户权限，就像给房子安装门锁，既要方便进出，又要确保安全。但在这个过程中，很多管理员，包括我自己早期，都踩过不少坑。理解这些误区并遵循最佳实践，能大大提升数据库的健壮性和安全性。

常见的误区：

“All Privileges”滥用： 很多时候为了图方便，直接给应用用户
```
GRANT ALL PRIVILEGES ON database.*
```
。这等同于给一个普通员工发了公司所有部门的最高权限，一旦应用被攻破，攻击者就能获得数据库的完全控制权，包括删除数据、修改结构等，后果不堪设想。
root
账户用于应用连接：这是最危险的误区之一。
```
root
```
账户拥有MySQL服务器的最高权限，如果应用程序直接使用
```
root
```
连接数据库，一旦应用代码存在SQL注入漏洞或被反编译，
```
root
```
账户的密码就可能泄露，导致整个数据库服务器被攻陷。
主机名使用
%
（通配符）：
```
CREATE USER 'user'@'%'
```
允许用户从任何IP地址连接。在测试环境或某些受严格防火墙保护的内部网络可能可以接受，但在生产环境，尤其是暴露在公网的服务，这会大大增加被暴力破解或未授权访问的风险。你应该尽可能地限制为特定的IP地址或IP段。
弱密码： 密码过于简单、容易猜测，或者长期不更换。这就像给你的金库只配了一把塑料锁。
不及时清理废弃用户： 项目下线了，或者员工离职了，但相关的数据库用户却一直留着。这些“僵尸账户”不仅占用资源，更是一个潜在的安全隐患。
过度依赖
FLUSH PRIVILEGES
：现代MySQL版本中，
```
GRANT
```
和
```
REVOKE
```
操作通常会立即生效，无需手动
```
FLUSH PRIVILEGES
```
。但一些老旧的教程或习惯让大家每次都执行，这虽然无害，但也可能让人误解其必要性。在某些场景下，例如直接修改
```
mysql.user
```
表（强烈不推荐），才需要显式刷新。

安全实践：

最小权限原则 (Principle of Least Privilege)： 这是金科玉律。每个用户或应用程序只授予完成其工作所必需的最小权限集合。例如，一个读取数据的报表应用，只需要
```
SELECT
```
权限；一个后台管理系统，可能需要
```
SELECT
```
,
```
INSERT
```
,
```
UPDATE
```
,
```
DELETE
```
，但通常不需要
```
CREATE
```
或
```
DROP
```
。
为每个应用或服务创建独立用户： 不要让多个应用共享同一个数据库用户。这样，当一个应用出现安全问题时，可以快速定位并限制受影响的范围，而不会波及其他应用。
限制主机连接： 尽可能将用户的主机限制为特定的IP地址或子网。例如，
```
'app_user'@'192.168.1.10'
```
而不是
```
'app_user'@'%'
```
。
使用强密码并定期更换： 密码应该足够复杂，包含大小写字母、数字和特殊字符，并有足够的长度。设置密码过期策略，强制用户定期更换密码。
定期审计权限： 定期检查现有用户的权限设置，确保它们仍然符合最小权限原则。移除不再需要的权限或用户。
利用视图 (Views) 和存储过程 (Stored Procedures)： 对于某些复杂或敏感的操作，可以创建视图来限制用户只能看到部分数据，或者创建存储过程来封装操作逻辑，然后只授予用户执行这些视图或存储过程的权限，而不是直接操作底层表的权限。
监控和日志： 启用MySQL的审计日志功能，记录用户的连接、权限变更和关键操作，以便在出现安全事件时进行追溯和分析。