答案：创建mysql用户需先用root登录，执行CREATE USER指定用户名、主机和密码，再用GRANT授予权限，如ALL PRIVILEGES或select、INSERT等，遵循最小权限原则，避免使用%通配符和ALL ON .，定期审计权限并刷新。
在MySQL中增加新用户并分配权限，核心操作就是通过
CREATE USER
语句创建用户，再利用
GRANT
语句赋予其相应的操作权限。这不仅是数据库管理的基础，更是保障数据安全的关键一环。毕竟，没有恰当的权限控制，你的数据库就像敞开大门的金库，随时可能面临风险。
解决方案
创建MySQL新用户并分配权限，这事儿说起来简单，但细节里藏着不少学问。我们一步步来，确保每一步都稳妥。
首先，你需要以拥有足够权限的用户（通常是
root
用户）身份登录到MySQL服务器。这就像拿到钥匙才能开门一样。
mysql -u root -p
接着，就是创建新用户。这里有几种方式，取决于你的需求。
1. 创建一个只能从特定主机（例如本地）访问的用户：
CREATE USER 'your_username'@'localhost' IDENTIFIED BY 'your_password';
这里的
'localhost'
意味着这个用户只能从运行MySQL服务器的同一台机器上连接。
2. 创建一个可以从任何主机访问的用户：
CREATE USER 'your_username'@'%' IDENTIFIED BY 'your_password';
'%'
是个通配符，表示任何IP地址或主机名。但请注意，在生产环境中，这通常不是最佳实践，除非你确实知道自己在做什么，并且有其他安全措施。我个人更倾向于指定具体的IP地址，比如
'192.168.1.100'
，这样安全性会高很多。
3. 如果你的MySQL版本较新（例如MySQL 8.0+），还可以指定认证插件：
CREATE USER 'your_username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';
这对于一些老旧的客户端连接可能有用，因为它们可能还不支持MySQL 8.0默认的
caching_sha2_password
认证插件。
用户创建好了，接下来就是分配权限。权限的粒度可以非常细致。
1. 授予数据库所有权限：
GRANT ALL PRIVILEGES ON your_database_name.* TO 'your_username'@'localhost';
your_database_name.*
表示对这个数据库下的所有表都拥有权限。
2. 授予特定表的特定权限：
如果你只想让用户对某个数据库的某个表有
SELECT
和
INSERT
权限，可以这样做：
GRANT SELECT, INSERT ON your_database_name.your_table_name TO 'your_username'@'localhost';
这对于那些只需要读写特定数据的应用来说非常有用，符合最小权限原则。
3. 授予全局权限（通常不推荐）：
GRANT ALL PRIVILEGES ON *.* TO 'your_username'@'localhost';
*.*
表示对所有数据库的所有表都有权限。这几乎等同于root权限，除非万不得已，否则不要这么做。
4. 赋予创建、修改、删除数据库的权限：
GRANT CREATE, ALTER, DROP ON *.* TO 'your_username'@'localhost';
这种权限通常只授予数据库管理员。
在所有权限操作之后，为了确保权限立即生效，通常需要刷新权限。虽然在现代MySQL版本中，
GRANT
语句通常会自动刷新，但养成这个习惯总没错：
FLUSH PRIVILEGES;
最后，你可以尝试用新创建的用户登录，并测试其权限是否符合预期。
mysql -u your_username -p -h localhost your_database_name
MySQL用户权限管理中常见的误区有哪些？
在我多年的数据库管理经验里，关于MySQL用户权限管理，有些“坑”是大家特别容易踩到的，我觉得很有必要拿出来聊聊。
首先，最常见的误区就是过度授权。很多人为了省事，直接给新用户
ALL PRIVILEGES ON *.*
，或者至少是
ALL PRIVILEGES ON your_database_name.*
。这就像你给一个只需要开门的人一把万能钥匙，他不仅能开门，还能开保险柜、开抽屉。一旦这个用户的密码泄露，或者他连接的应用出现漏洞，整个数据库的安全就岌岌可危了。我个人建议，一定要坚持“最小权限原则”，也就是只授予用户完成其工作所需的最低权限。一个应用如果只需要读取数据，那就只给
SELECT
权限；如果还需要写入，就加上
INSERT
、
UPDATE
、
。
其次，使用
root
用户进行应用连接。这个错误我见过太多次了。应用程序直接用
root
账号去连接数据库，简直是把数据库的命脉交到了应用手里。如果应用服务器被攻破，攻击者就能轻易获得
root
权限，对数据库为所欲为。正确的做法是为每个应用或服务创建独立的、拥有最小权限的用户。
再来，密码设置过于简单或直接硬编码在代码里。弱密码是所有安全问题的根源之一。
123456
、
password
这样的密码，基本上形同虚设。而且，把密码直接写死在配置文件或代码中，一旦代码仓库泄露，密码也就暴露了。现在有很多成熟的秘密管理方案（比如HashiCorp Vault），或者至少使用环境变量来存储敏感信息。
还有一个容易被忽视的点是，用户主机（Host）设置过于宽松。很多人习惯性地使用
'username'@'%'
来创建用户，这意味着这个用户可以从任何IP地址连接到MySQL。在开发环境可能没问题，但在生产环境，这会大大增加被未授权访问的风险。如果你的应用只部署在特定的几台服务器上，那么就应该明确指定这些服务器的IP地址，比如
'username'@'192.168.1.100'
。这样，即使密码泄露，攻击者也必须先突破到这些特定服务器上才能连接数据库。
最后，忘记刷新权限（
FLUSH PRIVILEGES
）。虽然在一些新版本的MySQL中，
GRANT
和
REVOKE
操作会自动刷新权限，但为了确保万无一失，特别是在一些旧版本或者复杂权限更改后，手动执行一下
FLUSH PRIVILEGES
总归是没错的。我见过不少情况，权限改了半天不生效，最后发现就是忘了这一步。
如何修改或撤销MySQL用户的现有权限？
修改或撤销MySQL用户的权限，这同样是数据库管理中不可或缺的一环。当用户的职责发生变化，或者某个应用不再需要某些权限时，及时调整是保障安全和合规性的必要步骤。
撤销权限：
撤销权限使用的是
REVOKE
语句，它的语法结构和
GRANT
非常相似，只是方向反了过来。
REVOKE privileges ON database.table FROM 'username'@'host';
举个例子，如果你之前给用户
app_user
在
my_app_db
数据库的所有表上授予了
DELETE
权限，现在想撤销它：
REVOKE DELETE ON my_app_db.* FROM 'app_user'@'localhost';
如果你想撤销用户对某个特定表的
INSERT
权限：
REVOKE INSERT ON my_app_db.users_table FROM 'app_user'@'localhost';
甚至可以一次性撤销所有权限（但保留用户本身）：
REVOKE ALL PRIVILEGES ON *.* FROM 'app_user'@'localhost';
请注意，
REVOKE
操作并不会删除用户，它只是收回了用户被授予的权限。
修改用户密码：
用户密码是需要定期更换的，或者当用户离职时，也需要立即修改密码。
对于MySQL 5.7及更早版本，你可以使用
SET PASSWORD
：
SET PASSWORD FOR 'app_user'@'localhost' = 'new_strong_password';
对于MySQL 8.0及更高版本，推荐使用
ALTER USER
，因为它更强大，可以同时修改其他用户属性：
ALTER USER 'app_user'@'localhost' IDENTIFIED BY 'new_strong_password';
删除用户：
当一个用户不再需要访问数据库时，最彻底的做法是直接删除这个用户。
DROP USER 'app_user'@'localhost';
这个操作会彻底移除用户账户及其所有关联的权限。这是一个不可逆的操作，所以在执行前务必确认。
刷新权限：
和
GRANT
一样，
REVOKE
和
ALTER USER
（特别是密码修改）通常也会自动刷新权限。但为了确保更改立即生效，特别是当你处理的是一个非常活跃的生产环境时，执行
FLUSH PRIVILEGES;
总是一个好习惯。我个人觉得，在生产环境做任何权限变动，多敲一行
FLUSH PRIVILEGES;
，心里会踏实很多。
在生产环境中，如何安全地管理MySQL用户和权限？
在生产环境中管理MySQL用户和权限，这可不是小事，它直接关系到你核心数据的安全。我个人觉得，这里面有几条原则是必须坚守的，否则迟早要出问题。
首先，最小权限原则是基石。这个原则再怎么强调都不为过。每个用户、每个应用，都只授予它们完成工作所需的最小权限集。比如，一个博客应用只需要读取文章和评论，那么就只给它
SELECT
权限；如果还需要发布新文章，才加上
INSERT
。绝不能为了方便，给所有应用都开
ALL PRIVILEGES
。这是我见过最常见的安全漏洞来源。
其次，为每个应用或服务创建独立的用户。不要让多个应用共享同一个数据库用户。这样做的最大好处是，一旦某个应用被攻破，或者其凭据泄露，受影响的范围可以被限制到最小。同时，通过审计日志，你也能更清晰地追踪到是哪个应用或服务进行了哪些操作。
再者，强密码策略和定期轮换。密码必须足够复杂，包含大小写字母、数字和特殊字符，并且长度要足够。更重要的是，要建立密码定期轮换的机制。如果手动轮换成本太高，可以考虑引入密码管理工具或自动化脚本。我之前就遇到过因为密码长期不更换，被撞库攻击的案例，教训非常深刻。
还有，严格控制用户的主机来源。尽可能避免使用
'%'
作为用户的主机。如果你的应用部署在固定的几台服务器上，就明确指定这些服务器的IP地址或主机名。这样，即使攻击者拿到了你的密码，也必须从这些特定的机器上才能连接数据库，大大增加了攻击的难度。
禁用或限制
root
用户的远程访问。
root
用户是数据库的超级管理员，它的权限是无限的。在生产环境中，应该尽可能地禁用
root
用户的远程登录，或者只允许它从极少数受信任的、高度安全的机器上登录。日常管理操作，应该使用一个拥有适当权限的非
root
管理用户。
定期审计和审查权限。权限不是一劳永逸的。随着业务的发展和人员的变动，用户的权限需求也会发生变化。因此，定期（比如每季度或半年）审查所有数据库用户的权限，移除不再需要的权限，或者调整不合理的权限，是非常必要的。我通常会写一些脚本来自动化这个审计过程，生成权限报告，这样能更清晰地看到谁拥有什么权限。
最后，利用安全功能和工具。MySQL本身提供了很多安全功能，比如ssl/TLS连接加密、审计日志、防火墙规则等。结合这些功能，可以进一步提升数据库的安全性。对于敏感数据，考虑使用数据加密。如果团队规模较大，可以考虑引入专业的秘密管理系统（如HashiCorp Vault），集中管理数据库凭据，实现动态凭据，避免凭据硬编码。这些工具虽然引入了额外的复杂度，但对于生产环境的安全性提升是巨大的。
