删 root 不会直接锁死，但若未预留具备 SUPER 或 SYSTEM_VARIABLES_ADMIN 权限的账号且 super_read_only=ON，则无法关闭只读、刷新权限或切换主从；备份账号无需 SUPER，应仅授 SELECT、LOCK TABLES、RELOAD、REPLICATION CLIENT；紧急接管账号 emerg_admin 必须严格限定来源并验证可用性。
直接删掉 root 用户本身不会导致权限锁死，真正危险的是：删完之后，没留任何具备 SUPER 或 SYSTEM_VARIABLES_ADMIN 权限的账号，又恰好启用了 super_read_only = ON —— 这时连 SET GLOBAL read_only = OFF 都执行不了，从库彻底写不进去，主从切换也会失败。
为什么删 root 后可能“进不去”
MySQL 8.0+ 默认启用 caching_sha2_password 插件，且权限校验强依赖服务端缓存。删掉 'root'@'localhost' 后，如果没提前建好替代高权限账号，会出现这些现象：
-
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement—— 连FLUSH PRIVILEGES都被拒 - 主从切换后，新主库仍处于只读状态，应用写请求全失败
- 备份脚本因缺
RELOAD或REPLICATION CLIENT权限卡在--master-data步骤，报错却只显示Access denied，不指明缺哪个权限
备份账号必须带 SUPER 吗？不，但要分清场景
绝大多数逻辑备份（mysqldump）根本不需要 SUPER。它真正需要的是：SELECT、LOCK TABLES、RELOAD（仅当用 --flush-logs）、REPLICATION CLIENT（仅当用 --master-data）。给备份账号加 SUPER 是严重越权，等于给了它绕过 super_read_only 的钥匙。
- 必须禁用：
GRANT SUPER ON *.* TO 'backup_user'@'localhost' - 推荐组合：
GRANT SELECT, LOCK TABLES, RELOAD, REPLICATION CLIENT ON *.* TO 'backup_user'@'localhost' - 若只备份单库（如
app_db），就把ON *.*换成ON app_db.*，避免暴露其他库 - 验证是否生效：
SHOW GRANTS FOR 'backup_user'@'localhost'，确认没继承角色或意外权限
删 root 前必须配好的“逃生通道”账号
这个账号不是为了备份，而是为了紧急接管——它得能关 super_read_only、刷权限、切主从。它不能叫 root，但权限要等效，且登录来源必须严格限定：
- 创建命令：
CREATE USER 'emerg_admin'@'127.0.0.1' IDENTIFIED BY 'xxx' REQUIRE SSL; - 授最小必要高权限：
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, SUPER, SYSTEM_VARIABLES_ADMIN ON *.* TO 'emerg_admin'@'127.0.0.1' - 关键限制：只允许通过本地 socket 或
127.0.0.1TCP 登录（配合bind-address = 127.0.0.1），禁止通配符% - 测试方式：从数据库服务器本机执行
mysql -u emerg_admin -p -h 127.0.0.1，确认能连上并执行SET GLOBAL super_read_only = OFF;
最难的不是语法对不对，而是删 root 前，你得确认 emerg_admin 账号已存在、密码没写错、SSL 证书路径配置正确、且 MySQL 配置里没漏掉 require_secure_transport = ON 这类强制要求——少一个条件，就真锁死了。
