MySQL新手用户管理疑问：数据库用户与业务用户的处理方式

嘿，我来帮你理清这些MySQL用户相关的疑问，一个个给你拆解：

1. Workbench创建的用户是不是客户登录数据库用的？ #

没错，你在MySQL Workbench里创建的这个用户就是数据库的登录账户——如果你的场景是让客户直接连接数据库（比如小型内部工具、测试环境），那他们登录时用的就是这个用户名和密码。不过要提醒下：生产环境里几乎不会让终端客户直接连数据库，通常是通过应用程序作为中间层处理，客户只需要登录应用就行，不用接触数据库账户。

2. 存储这些用户的表在哪里？ #

MySQL的系统用户信息都存在自带的mysql系统数据库里的user表中。你可以通过这条命令查看核心信息：

SELECT user, host, authentication_string FROM mysql.user;

这个表是MySQL的核心系统表，管理着所有数据库账户的权限、加密密码等关键配置。

3. 能不能给这个系统用户表加邮箱、全名、积分等字段？ #

强烈不建议这么做！MySQL的系统表结构和数据库内核紧密绑定，自定义修改会带来一堆风险：

• 数据库版本升级时，系统表可能被重置或结构变更，你的自定义字段会直接丢失，甚至导致升级失败；
• MySQL内部的权限验证逻辑完全不会识别这些自定义字段，加了也起不到业务作用；
• 随意篡改系统表可能触发未知的稳定性问题，严重时会导致数据库无法正常启动。

4. 是不是要自建客户表来补充业务字段？ #

这才是正确的思路！你应该创建独立的业务客户表（比如customer_table），把邮箱、全名、积分这些业务相关的信息存在这里。如果需要和数据库用户关联，可以在自建表里加一个字段（比如db_username），用来对应MySQL系统用户的用户名，这样就实现了「数据库权限账户」和「业务客户信息」的职责分离。

5. 还有哪些遗漏的要点？ #

• 权限最小化原则：给客户的MySQL账户只分配他们必需的权限，比如只能访问特定业务数据库的SELECT/INSERT权限，绝对不要给ALL PRIVILEGES全局权限，避免数据泄露或误操作；
• 优先通过应用层中转：生产环境下，推荐用应用作为中间件，应用用一个权限合适的数据库账户连接，客户登录应用后由应用代为操作数据库——这样既安全，也不用给每个客户都创建MySQL账户；
• 密码安全存储：MySQL的用户密码是加密存储在mysql.user的authentication_string字段的，不要在自建客户表里存明文密码，要用哈希算法（比如bcrypt、Argon2）加密后再存储。

内容的提问来源于stack exchange，提问作者VikGra