不中断。直接修改权限表本身不会中断服务，但误操作（如删关键权限）或未及时FLUSH PRIVILEGES会导致应用报Access denied；GRANT/REVOKE自动生效，无需FLUSH，而直改mysql.user表后必须执行FLUSH PRIVILEGES才能使新权限对新连接生效。
直接改权限会中断线上服务吗
会，但只在特定操作下发生。修改用户权限本身不重启 mysql，但 flush privileges 会刷新权限缓存，可能触发连接重置；更危险的是误删权限导致应用连不上库——比如不小心取消了 select 或 insert，php 或 java 应用立刻报 access denied for user。不要在高峰期执行，尤其避免对正在被业务使用的账号直接点「执行」。
实操建议：
- 先用
SHOW GRANTS FOR 'app_user'@'10.20.30.%';查当前权限，截图或复制留底 - 在 phpMyAdmin 的「SQL」标签页里执行变更，而不是依赖界面勾选（界面有时生成不完整语句）
- 改完立刻用同账号连一次测试库验证，别等上线才发现问题
- 如果只是加权限，
GRANT后可不FLUSH PRIVILEGES（MySQL 5.7+ 自动生效）；但删权限必须REVOKE+FLUSH
为什么不能在 phpMyAdmin 界面里勾选“所有权限”
勾选「Check All」会授予 SUPER、SHUTDOWN、FILE 这类服务器级权限，等于把 MySQL 实例的开关、日志读写、内存控制权交出去。一旦该账号被泄露或误配置，攻击者能直接 dump 内存、读取 /etc/passwd、kill 主从线程——不是“能查数据”，而是“能关掉整个数据库”。
真实场景中，99% 的业务账号只需要这几项：
-
SELECT、INSERT、UPDATE、DELETE -
CREATE、DROP（仅限需要建表的运维账号） -
ALTER、INDEX（迁移脚本需要） - 绝对不勾
GRANT OPTION—— 它无法被上级回收，且允许该用户再授予权限
如何限制用户只能访问指定库，又不卡住连接
phpMyAdmin 没有“默认数据库”设置项，所谓“限制访问指定库”，本质是移除全局权限 + 单独授权目标库。但如果只在「Database-specific privileges」里勾选 app_db 的权限，而没处理全局权限区域，用户仍可能看到其他库名（只是进不去），甚至因权限冲突导致 PDO 连接时抛 Unknown database 错误。
立即学习“PHP免费学习笔记（深入）”；
正确做法：
- 进入「Edit privileges」→ 先在「Global privileges」区域取消所有勾选（包括空的「Select all」）
- 滚动到「Database-specific privileges」→ 点「Add privileges on the following database」→ 选
app_db→ 勾所需权限 - 保存后，如果应用连接字符串没带
dbname=app_db，需确认其代码是否显式USE app_db，否则首次查询会失败 - 注意主机名匹配：
'app_user'@'10.20.30.%'和'app_user'@'localhost'是两个独立账号，权限不互通
权限改完应用还是连不上？先查这三处
常见假象是“权限已改”，实际卡在更底层。典型错误现象：phpMyAdmin 显示授权成功，但 Laravel 报 SQLSTATE[HY000] [1045] Access denied，或 Python pymysql 连接超时。
排查顺序：
- 确认 MySQL 用户 host 是否匹配：应用从
192.168.1.5连，但权限只给了'user'@'127.0.0.1'→ 必须补'user'@'192.168.1.5'或通配'user'@'%'（后者慎用） - 检查认证插件：MySQL 8.0+ 默认用
caching_sha2_password，老版本 PHP 驱动不支持 → 执行ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 确认防火墙和 SELinux：
iptables -L | grep 3306看端口是否放行；sestatus查 SELinux 是否拦截 socket 连接
