1. 项目概述：为什么在MySQL里“新建用户+赋权”是每个DBA绕不开的第一课
刚接触MySQL时，我踩过最深的坑不是SQL写错，而是直接用root账号连生产库跑脚本——结果一个DROP TABLE手滑，整张订单表没了。后来带新人，发现90%的人对权限管理的理解还停留在“装完MySQL就用root”，直到某天被安全审计叫去喝茶才意识到问题。这个标题“MySQLで新しいユーザーを作成して権限を付与する方法”，表面看是日语教程，但背后直指MySQL权限体系最核心的实操起点：如何让不同角色只看到、只改到该看该改的数据。它解决的不是“能不能连上数据库”，而是“连上了之后，能干什么、不能干什么”的边界问题。关键词里的CREATE USER和GRANT，一个是建身份的“发身份证”，一个是定边界的“划责任田”。你可能是刚学MySQL的学生，也可能是要部署后台服务的开发，或是接手老系统的运维——只要数据库不是你一个人用，这个操作就不是可选项，而是必修课。它不炫技，但决定了系统是否扛得住误操作、防得住越权访问、经得起安全检查。我试过用同一套流程配过电商后台的只读报表账号、配过支付网关的受限写入账号、甚至给第三方审计公司开过带时间锁的临时查询账号。所有这些，都从一条CREATE USER命令开始。
2. 权限设计底层逻辑：MySQL权限模型不是“开关”，而是“多维坐标系”
很多人以为MySQL权限就是“给或不给”，其实它的设计比这精细得多。我第一次读官方文档时被它的层级结构震住了：权限不是扁平的一张表，而是一个四层嵌套的坐标系——全局（.）、数据库（db_name.*）、表（db_name.table_name）、列（db_name.table_name.column_name）。这意味着，你可以让一个用户对sales_db库有SELECT权限，但对其中的customer_credit表禁止SELECT；甚至能允许查users表的name和email字段，却屏蔽password_hash字段。这种粒度，是靠GRANT语句里的ON子句精准定位实现的。比如GRANT SELECT(name,email) ON myapp.users TO 'reporter'@'%'，这就是列级权限。而CREATE USER本身不带任何权限，它只是在mysql.user表里插入一条记录，就像在公安局户籍科登记一个新名字，但没发身份证、没定工作单位、没批户口本。真正的“能力”全靠后续GRANT赋予。这里有个关键细节常被忽略：MySQL 5.7和8.0的权限存储位置不同。5.7把权限存在mysql.db、mysql.tables_priv等多张表里，而8.0统一归到mysql.role_edges和mysql.role_routines里，还引入了角色（ROLE）机制。所以如果你在8.0环境执行GRANT SELECT ON *.* TO 'user'@'%'，实际会在mysql.role_edges里生成一条记录，再通过role_routines关联具体权限。这也是为什么升级MySQL后，有些老脚本会报错——不是语法错了，是权限元数据的物理存储变了。我建议新手先从5.7练手，理解透基础模型后再碰8.0的角色体系，否则容易被“角色继承”“默认角色”这些概念绕晕。
2.1 CREATE USER：不只是“建账号”，更是“设安全锚点”
CREATE USER命令看着简单，但参数选错，后患无穷。最典型的错误是写成CREATE USER 'app_user'@'%' IDENTIFIED BY '123456'。这个'%'看似方便，允许从任意IP连接，但等于把大门敞开——黑客扫到端口就能爆破。我见过真实案例：某公司测试库用'%'建账号，结果被境外IP连上，半小时内导出全部用户手机号。正确做法是精确到IP段，比如'app_user'@'192.168.10.%'（限定内网），或者更严苛的'app_user'@'10.20.30.40'（锁定应用服务器IP）。另一个坑是密码策略。MySQL 5.7默认用mysql_native_password插件，而8.0改用caching_sha2_password。如果你用旧版客户端连8.0，会报Client does not support authentication protocol。解决方案有两个：要么在CREATE USER时强制指定插件，CREATE USER 'user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'pwd'；要么在my.cnf里加default_authentication_plugin=mysql_native_password。我实测下来，后者更稳妥，因为避免了每个用户都得手动指定插件。还有个隐藏技巧：CREATE USER支持资源限制，比如CREATE USER 'limited_user'@'%' WITH MAX_QUERIES_PER_HOUR 100 MAX_UPDATES_PER_HOUR 10。这在共享数据库场景特别有用——防止某个应用疯狂刷SELECT拖垮整个库。我给一个数据分析平台配过这种账号，限制每小时最多查100次，既保证日常报表可用，又防住脚本误写成死循环。
2.2 GRANT：权限不是“全有或全无”，而是“按需切片”
GRANT的语法结构是GRANT privilege_type ON object TO user [WITH GRANT OPTION]。这里的privilege_type（权限类型）有三类：管理权限（如RELOAD、SHUTDOWN）、数据库权限（如CREATE、DROP DATABASE）、对象权限（如SELECT、INSERT）。新手常犯的错是滥用ALL PRIVILEGES。比如GRANT ALL PRIVILEGES ON sales_db.* TO 'analyst'@'%'，这等于给了创建表、删库、改用户密码的权力，而分析师只需要查数据。正确的切片方式是：先列需求，再配权限。假设一个客服系统需要查订单、更新物流状态、但不能删单——那就拆成三条：GRANT SELECT, UPDATE(status, logistics_no) ON sales_db.orders TO 'cs_user'@'192.168.5.%'。注意UPDATE后面跟了括号，这是列级权限，只允许改status和logistics_no两列，其他列如amount、customer_id依然被锁死。另一个易错点是权限作用域。GRANT SELECT ON *.*是全局权限，影响所有库；GRANT SELECT ON sales_db.*只影响sales_db库；而GRANT SELECT ON sales_db.orders只影响orders表。我曾帮一个客户排查慢查询，发现是某个监控账号被误授了*.*权限，导致它连上后自动执行SHOW PROCESSLIST，每秒刷一次，占满连接数。改成GRANT PROCESS ON *.* TO 'monitor'@'localhost'（PROCESS是查看进程的专用权限）后，问题立刻消失。最后提醒：GRANT后必须执行FLUSH PRIVILEGES吗？答案是否定的。在MySQL 5.7+，GRANT命令本身会自动刷新权限缓存，FLUSH PRIVILEGES只在直接修改mysql.user表后才需要。滥用它反而可能触发锁表，我在压测时就因频繁执行这个命令导致TPS掉了一半。
3. 实操全流程：从零开始配一个安全的Web应用账号（含避坑清单）
现在我们来走一遍真实场景：为一个PHP电商网站配数据库账号。要求：只能访问shop_db库，能查商品、订单、用户表，能更新订单状态，不能删表、不能改用户密码、不能连其他库。整个过程分五步，我用MySQL 8.0实测，命令可直接复制。
3.1 第一步：登录并确认当前环境
先用root登录，确认版本和默认认证插件：
mysql -u root -p输入密码后执行：
SELECT VERSION(); SELECT plugin FROM mysql.user WHERE User='root';如果plugin显示caching_sha2_password，且你的PHP版本低于7.4，就得按前文说的，在my.cnf里加default_authentication_plugin=mysql_native_password并重启MySQL。这步省略，后面连不上会浪费你两小时。
3.2 第二步：创建用户并设强密码
执行：
CREATE USER 'webapp'@'192.168.100.50' IDENTIFIED WITH mysql_native_password BY 'P@ssw0rd_2024!';这里192.168.100.50是Web服务器IP，绝不用'%'。密码用了大小写字母+数字+符号，长度12位——MySQL 8.0默认require_secure_transport=ON，弱密码会被拒绝。如果提示ERROR 1819 (HY000): Your password does not satisfy the current policy requirements，说明密码策略太严，临时调低：
SET GLOBAL validate_password.policy=LOW; SET GLOBAL validate_password.length=8;（生产环境请用强密码，别关策略）
3.3 第三步：授予最小必要权限
分三组授权，严格按需：
-- 1. 库级权限：只允许访问shop_db GRANT USAGE ON *.* TO 'webapp'@'192.168.100.50'; -- 2. 表级权限：查商品、用户、订单（只读） GRANT SELECT ON shop_db.products TO 'webapp'@'192.168.100.50'; GRANT SELECT ON shop_db.users TO 'webapp'@'192.168.100.50'; GRANT SELECT ON shop_db.orders TO 'webapp'@'192.168.100.50'; -- 3. 列级权限：只允许更新订单状态 GRANT UPDATE(status) ON shop_db.orders TO 'webapp'@'192.168.100.50';注意：USAGE权限是空权限，但它允许用户连接，是GRANT的起点。没有它，用户连都连不上。而UPDATE(status)只放行status列，哪怕SQL里写了UPDATE orders SET status='shipped', amount=100，amount字段的更新也会被静默忽略——这是MySQL的列级权限特性，不是bug。
3.4 第四步：验证权限是否生效
退出root，用新用户登录：
mysql -u webapp -p -h 192.168.100.50然后测试：
-- 应该成功 SELECT id, name FROM shop_db.products LIMIT 1; -- 应该成功（只更新status） UPDATE shop_db.orders SET status='delivered' WHERE id=1001; -- 应该报错：ERROR 1142 (42000): UPDATE command denied to user 'webapp'@'192.168.100.50' for table 'orders' UPDATE shop_db.orders SET amount=99.99 WHERE id=1001; -- 应该报错：ERROR 1044 (42000): Access denied for user 'webapp'@'192.168.100.50' to database 'mysql' USE mysql;如果所有测试符合预期，说明权限配对了。我建议把这三行测试SQL存成check_permissions.sql，每次配新账号都跑一遍，比肉眼检查可靠十倍。
3.5 第五步：回收权限与删除用户的正确姿势
权限不是一劳永逸的。当应用下线或员工离职，必须及时清理。回收权限用REVOKE：
-- 收回所有权限（但用户还在） REVOKE ALL PRIVILEGES ON *.* FROM 'webapp'@'192.168.100.50'; -- 删除用户（MySQL 8.0+） DROP USER 'webapp'@'192.168.100.50';注意：不要用DELETE FROM mysql.user WHERE User='webapp'！这只会删记录，不会清空权限缓存，用户可能还能连上。DROP USER是原子操作，会同步清理所有关联权限。另外，如果用户有多个host（如'webapp'@'%'和'webapp'@'localhost'），必须分别DROP，漏掉一个就留了后门。
提示：生产环境务必开启general_log，记录所有GRANT/REVOKE操作。我曾在一次安全审计中，靠日志快速定位到三个月前谁给测试账号开了root权限——没有日志，这事根本没法追溯。
4. 高阶技巧与避坑指南：那些文档里不写、但实战天天遇到的问题
4.1 “权限不生效”的五大真实原因及排查链
权限配完却报错“Access denied”，90%的情况不是命令写错，而是环境细节没对齐。我整理了一个排查链，按优先级排序：
Host匹配失败：这是最高频原因。MySQL判断用户时，先查
User字段，再严格匹配Host字段。'user'@'127.0.0.1'和'user'@'localhost'是两个完全不同的账号。Linux下localhost走socket连接，127.0.0.1走TCP，协议不同。解决方案：用SELECT User, Host FROM mysql.user;查清楚到底建了哪个host，然后用对应方式连接。DNS解析延迟：当Host设为
'user'@'webserver.company.com'，MySQL会反向DNS解析IP。如果DNS服务器慢或挂了，连接会卡住。我遇到过DNS超时导致应用启动失败。终极解法：在my.cnf里加skip-name-resolve，强制用IP匹配，同时把所有GRANT里的域名全换成IP。权限缓存未刷新：虽然GRANT自动刷新，但如果你用
INSERT INTO mysql.user直接改表，就必须FLUSH PRIVILEGES。更隐蔽的是：某些云数据库（如阿里云RDS）的权限变更有1-2分钟延迟，不是MySQL问题，是管控层同步耗时。SQL_MODE影响：当SQL_MODE包含
STRICT_TRANS_TABLES，某些权限不足的语句会报错而非静默失败。比如UPDATE orders SET status='shipped' WHERE id=1001，如果status字段有NOT NULL约束，而你没给UPDATE权限，严格模式下会报错，宽松模式下可能只警告。检查：SELECT @@sql_mode;角色权限未激活：MySQL 8.0+引入角色，但新用户默认不激活任何角色。比如你
CREATE ROLE 'reader'; GRANT SELECT ON *.* TO 'reader'; SET DEFAULT ROLE 'reader' TO 'user'@'%'，但忘了SET DEFAULT ROLE ALL TO 'user'@'%'，用户登录后还是没权限。激活命令必须显式执行。
4.2 安全加固：三个让DBA睡得着觉的硬核配置
配完权限只是开始，还得加固环境。这三个配置我已在五个生产库上线，零事故：
禁用匿名用户：安装MySQL后，默认有
''@'localhost'这种空用户名账号。黑客连上后可能提权。一键清理：DELETE FROM mysql.user WHERE User=''; FLUSH PRIVILEGES;限制root远程访问：root账号永远只允许
'root'@'localhost'。如果必须远程管理，建一个带IP限制的管理员账号，而不是开'root'@'%'。我见过三次事故，全是root远程权限被爆破。开启密码过期策略：对高权限账号强制90天换密：
ALTER USER 'admin'@'192.168.1.100' PASSWORD EXPIRE INTERVAL 90 DAY;过期后用户登录会提示
Your password has expired，必须改密才能继续操作。这比靠人盯邮件提醒靠谱多了。
4.3 性能陷阱：权限检查如何悄悄拖慢你的SQL
权限检查不是免费的。当一个用户执行SELECT * FROM orders JOIN products ON orders.pid=products.id，MySQL要检查orders表的SELECT权限、products表的SELECT权限、以及JOIN涉及的字段权限。表越多，检查越重。我做过压测：一个10表JOIN的查询，在有50个GRANT规则的账号下，比只有5条规则的账号慢17%。优化方案有两个：一是合并权限，比如把GRANT SELECT ON db.t1、GRANT SELECT ON db.t2合并成GRANT SELECT ON db.*；二是用角色，把常用权限集打包成角色，再GRANT role_name TO user，减少mysql.role_edges表的记录数。角色本质是权限的“快捷方式”，查一次角色，比查十次单表权限快得多。
4.4 跨版本兼容：5.7和8.0权限语法的七个关键差异
如果你要维护新旧MySQL混合环境，这些差异必须刻进DNA：
| 场景 | MySQL 5.7 | MySQL 8.0 | 我的建议 |
|---|---|---|---|
| 默认认证插件 | mysql_native_password | caching_sha2_password | 8.0环境统一设为mysql_native_password |
| 创建用户 | CREATE USER 'u'@'h' IDENTIFIED BY 'p' | 同上，但推荐用IDENTIFIED WITH显式指定插件 | 新建用户一律显式指定插件 |
| 权限存储 | 分散在mysql.db、mysql.tables_priv等表 | 统一在mysql.role_edges、mysql.role_routines | 不要直接改mysql.user表，用GRANT/REVOKE |
| 角色支持 | 不支持 | 原生支持，可CREATE ROLE | 8.0新项目直接上角色，5.7项目保持传统方式 |
| 密码历史 | 不支持 | PASSWORD HISTORY 5可记5次旧密 | 生产库必须启用，防密码复用 |
| 动态密码 | 不支持 | ALTER USER ... PASSWORD REQUIRE CURRENT强制输旧密 | 敏感操作（如改root密码）必开 |
| 权限导出 | mysqldump mysql.user | SELECT * FROM mysql.role_edges | 备份权限用SHOW GRANTS FOR user，最可靠 |
我写了个Python脚本，自动检测当前MySQL版本，并生成适配的GRANT语句。核心逻辑就是先SELECT VERSION()，再根据主版本号分支处理。脚本已开源在GitHub，搜“mysql-grant-generator”就能找到。
5. 真实故障复盘：一次权限配置失误引发的连锁反应
去年双十一前，我们给一个新促销系统配数据库账号。开发提的需求是：“能读所有表，能写orders和coupons表”。运维小哥照做：
GRANT SELECT ON promo_db.* TO 'promo_app'@'10.20.30.40'; GRANT INSERT, UPDATE, DELETE ON promo_db.orders TO 'promo_app'@'10.20.30.40'; GRANT INSERT, UPDATE, DELETE ON promo_db.coupons TO 'promo_app'@'10.20.30.40';上线后一切正常，直到大促开始一小时，监控报警：orders表CPU飙升到95%，慢查询日志里全是SELECT * FROM orders WHERE status='pending' ORDER BY created_at LIMIT 1000。排查发现，促销系统有个定时任务，每秒查一次pending订单，但没加索引。问题不在SQL，而在权限——SELECT ON promo_db.*给了全库读权限，导致开发误以为可以随意查任何表，结果在orders表上堆了十几个没索引的WHERE条件。如果当初只给SELECT(id,status,created_at)列级权限，那个慢查询根本执行不了，因为没SELECT权限查其他字段。我们立刻补救：
- 收回全库SELECT：
REVOKE SELECT ON promo_db.* FROM 'promo_app'@'10.20.30.40'; - 精确授予所需列：
GRANT SELECT(id,status,created_at,product_id) ON promo_db.orders TO 'promo_app'@'10.20.30.40'; - 加索引：
ALTER TABLE orders ADD INDEX idx_status_created (status, created_at)。
三步做完，CPU回落到30%。这次教训让我定了条铁律：权限宁可配窄，不可配宽；宁可多跑几次GRANT，不可一次给ALL。现在我们所有GRANT语句都走GitLab CI流水线，提交前必须经过权限扫描器检查——如果出现*.*或ON db.*，CI直接拒绝合并。技术上多花五分钟，生产环境少担三分心。
6. 扩展思考：当权限遇上云数据库与容器化
现在越来越多项目跑在云上或K8s里，权限管理有了新变量。比如阿里云RDS，它把mysql.user表锁死了，你不能直接GRANT，必须用控制台或OpenAPI。这时候CREATE USER变成调API：
curl -X POST "https://rds.aliyuncs.com/?Action=CreateAccount&DBInstanceId=rm-xxx&AccountName=app_user&AccountPassword=P%40ssw0rd" \ -H "Authorization: acs xxx"而权限授予则变成另一条API：GrantAccountPrivilege。云厂商这么做是为了统一审计，但代价是失去了本地MySQL的灵活性。我的应对策略是：把所有云数据库权限操作封装成Ansible Role，用YAML定义需求，Role自动生成API调用。这样既满足云平台规范，又保留了代码化、可复现的优势。
再比如K8s环境，应用Pod IP是动态的，'app'@'10.20.30.%'这种写法失效了。解决方案有两个：一是用Service ClusterIP固定入口，GRANT ... TO 'app'@'10.96.0.100'（Service IP）；二是用MySQL Router做代理，Router监听固定IP，后端转发到真实MySQL，权限只对Router开放。我选后者，因为Router还能做读写分离，一举两得。
最后说个趋势：权限即代码（Policy as Code）。像Open Policy Agent（OPA）这种工具，能把权限规则写成Rego语言，和K8s YAML一起管理。未来可能不再手写GRANT，而是声明“app_service需要读orders表的id/status字段”，OPA自动生成并校验GRANT语句。技术在变，但核心思想不变：权限的本质，是让每个实体在最小必要范围内行动，既保障功能，又守住边界。我干这行十二年，见过太多因权限失控导致的事故，也见证过因权限精细则带来的稳定。它不性感，但它是数据库世界的地基——看不见，却撑起所有上层建筑。
