MySQL 用户权限怎么分配？应用账号、授权范围与验证
为网站创建 MySQL 账号时，最重要的是说明它需要对哪些库执行哪些动作。一个应用能够连接，不代表它应该创建用户、访问其他业务库或授予别人权限。本文以 MySQL 8.4 为例，示例数据库和来源地址都要替换为实际环境。
先分清账号名称与连接来源
MySQL 账号由用户名和主机部分共同确定。同名用户从不同来源连接，可能匹配不同账号，因此排查权限时不能只看用户名。应用经过代理或 NAT 时，也要核对数据库最终看到的来源。
为运行应用、执行结构迁移、只读报表和人工管理分别规划身份。共享一个超级管理员账号看似省事，却让权限回收、审计和凭据轮换都更困难。账号创建行为和认证选项可查MySQL CREATE USER 文档。
给已有应用账号授予必要操作
假设 site_app 的来源账号已按安全流程创建，网站只需要对 sitedb 读写业务数据，可以从明确授权开始：
GRANT SELECT, INSERT, UPDATE, DELETE
ON sitedb.*
TO 'site_app'@'10.20.0.20';
SHOW GRANTS FOR 'site_app'@'10.20.0.20';
这只是演示常见数据操作，不保证适合每个框架。应用使用存储程序或其他功能时，应据实际需要增加相应权限，不能因为一个报错就把授权扩大到所有库、所有操作。
数据库与账号应事先存在，操作由具备合法授权能力的管理员执行。直接使用 CREATE USER、GRANT 等正式语句后，不需要为了“刷新”再去修改系统权限表。各授权范围与限制见MySQL GRANT 手册。
结构迁移与日常运行分开
发布期间可能需要 CREATE、ALTER 等结构变更权限，但应用处理普通用户请求时未必需要。可以采用独立迁移身份，在受控发布步骤中使用，并记录执行内容与结果。
并非所有现成应用都支持这种分离。若软件确实在运行时修改结构，应先理解其官方部署要求，再制定可维护的权限范围，不能盲目撤权导致业务中断。重点是每项额外权限都有明确理由，而不是机械套用一个最小列表。
迁移账号的凭据也不应长期留在 Web 进程可读取的位置。程序漏洞一旦出现，能读取到什么凭据，就可能获得相应能力；只把不同账号写在同一个公开配置里并没有建立有效边界。
用实际连接身份检查结果
在应用使用的连接路径中执行：
SELECT USER(), CURRENT_USER();
SHOW GRANTS;
前者有助于比较连接提交的身份与实际匹配账号，后者查看当前授权。角色或不同连接来源也可能影响实际能力，应使用正式应用配置复核，而不只在本地管理员会话里测试。
验收应包括必要查询、受控事务和应用关键流程，同时确认无权访问其他业务数据。不要为了测试拒绝行为而对生产表执行破坏性语句；可以通过专门测试对象和授权检查完成验证。
撤回权限与轮换凭据有顺序
先导出现有授权并记录用途，再撤回已确认多余的权限。撤权之前检查后台任务、备份和定时作业是否共用该账号，避免只验证网站首页就忽略夜间作业。
凭据轮换应先准备新连接方式、部署并验证应用，再撤销旧凭据或旧账号。出现问题时按保留记录恢复必要授权，不能临时重新开放全库管理权限。最终把账号、来源、库范围、维护人和轮换方式写入交接清单，使权限能够随着业务变化有序调整。