MySQL权限控制不由配置文件实现，真正权限管理依赖mysql.user等系统表及GRANT/REVOKE语句；skip-grant-tables会跳过权限校验，导致无密码、全权限访问，仅适用于紧急恢复，绝不可用于常规权限限制。
MySQL配置文件里根本不能限制用户权限
权限控制不是靠my.cnf或my.ini里的某个开关实现的。skip-grant-tables确实能绕过权限系统，但它不是“限制权限”的手段，而是彻底关闭权限校验——这就像拔掉门锁来“限制别人进门”一样荒谬。
真正控制权限的地方只有两个：mysql.user表（存储全局权限）和mysql.db、mysql.tables_priv等系统表（存储库/表级权限）。配置文件只负责服务启动行为，不参与运行时鉴权逻辑。
skip-grant-tables 启用后会发生什么
加了这个参数，MySQL启动时会跳过加载权限表，所有连接都以root@localhost身份进入，且拥有全部权限。这不是“降权”，是“无权校验”——连密码都不需要，连DROP DATABASE mysql都能直接执行。
- 任何本地连接（哪怕用
-u nobody）都会获得最高权限 -
SELECT USER(), CURRENT_USER()返回的都是root@localhost，掩盖真实身份 - 所有
GRANT/REVOKE语句失效，因为权限表根本没加载 - 如果误配在生产配置中且重启生效，等于主动交出数据库控制权
想限制权限，必须走 SQL 授权流程
配置文件能做的顶多是约束服务本身的行为（比如绑定bind-address = 127.0.0.1防外连），但用户能做什么，只能靠GRANT语句一条条写清楚。
常见误操作是以为改了my.cnf里的user字段就能限制登录用户——那个user只是指定mysqld进程以哪个系统用户身份运行，和MySQL账户完全无关。
- 新建账号必须用
CREATE USER 'app'@'10.0.1.%' IDENTIFIED BY 'pwd' - 最小权限原则：只给
SELECT, INSERT，就别给UPDATE；只给单库，就别用*.* - 权限变更后必须
FLUSH PRIVILEGES（仅在直接改系统表时需要，正常GRANT不用） - 删除账号用
DROP USER 'olduser'@'%'，而不是只删mysql.user行
为什么有人想用 skip-grant-tables 做权限管理
通常是忘了密码，或者误删了root用户，临时想“先进去再说”。但把它当成常规权限策略，等于把急救锤当日常门把手用。
更隐蔽的风险是：某些自动化部署脚本会硬编码skip-grant-tables来“确保初始化成功”，结果上线后忘记删——这种配置一旦被扫描到，等于裸奔。
真正该盯住的是mysql.user表里plugin字段是否为mysql_native_password（避免auth_socket导致无法密码登录），以及host字段是否过度宽泛（比如'%' 比'10.0.1.%'危险得多）。
