MySQL 的安全模式（Safe Mode）通常指在跳过权限验证或限制特定功能的状态下启动数据库，常用于管理员密码遗忘、权限损坏等紧急维护场景。在这种特殊状态下创建账号，既需要理解安全模式的运行机制，也要清楚操作后的权限恢复流程，避免因配置不当留下安全隐患。
一、理解 MySQL 安全模式
1. 什么是安全模式
MySQL 的安全模式并非单一概念，通常包含两种常见形态：
- 跳过权限表模式（Skip-Grant-Tables）
启动时添加 --skip-grant-tables 参数，MySQL 不再加载权限系统，任何客户端无需认证即可连接，并拥有完全控制权。这是最常用的紧急维护模式。 - 只读模式或限制模式
某些场景下，安全模式也指代限制写入操作、禁止网络连接或仅允许本地访问的启动状态，用于数据抢救或防止误操作扩散。
本文主要围绕第一种形态------跳过权限表模式展开，因为这是创建账号时最常涉及的紧急场景。
2. 安全模式的风险
跳过权限验证意味着数据库完全暴露：
- 任何能连接到数据库端口的用户都拥有 root 权限
- 无法区分用户身份，审计日志失去意义
- 若数据库端口对外网开放，将面临严重安全威胁
因此，安全模式下的操作必须遵循"快速进入、完成必要任务、立即退出"的原则。
二、进入安全模式的场景
1. 典型使用场景
- 管理员账号完全丢失
root 密码遗忘，且没有其他具备 SUPER 权限的账号可用，无法通过正常途径重置密码。 - 权限表损坏mysql.user 或其他权限表因异常操作、磁盘故障导致损坏，MySQL 无法正常启动或认证。
- 批量账号重建
在测试环境或迁移场景中，需要绕过正常权限检查快速重建一批账号。
2. 非必要不使用
如果仍能通过正常认证连接数据库，即使使用 root 账号，也应避免进入安全模式。正常连接下使用 CREATE USER 和 GRANT 语句是更规范、更安全的账号创建方式。
三、安全模式下创建账号的完整流程
1. 首先停止mysql数据库服务
2. 进入mysql数据库的bin目录下，打开cmd,以--skip-grant-tables模式登录数据库，执行如下指令
3. 安全模式启动MYSQL数据库服务后，在MYSQL数据库的bin目录下打开第二个cmd
4. 以root账号登录mysql数据库:mysql -uroot
5. 查看数据库，执行SHOW DATABASES;
6. 刷新权限表：FLUSH PRIVILEGES;
7. 创建只读账号密码
bash
#mysql5.6版本以上执行语句
CREATE USER '账号'@'%' IDENTIFIED BY '密码';
GRANT SELECT ON 数据库.* TO '账号'@'%';
#mysql5.6版本以下执行语句
CREATE USER '账号'@'%' IDENTIFIED BY '密码';
GRANT SELECT ON 数据库.* TO '账号'@'%'; 
8. 刷新权限表：FLUSH PRIVILEGES;
9. 查看是否已创建readonly账号成功：select * from mysql.user\G;
10. 创建账号成功后，退出执行语句的cmd
11. 关闭安全模式下启动的MYSQL数据库服务的cmd（直接kill掉服务）
12. 启动mysql数据服务，用新创建的账号密码登录数据库
四、安全模式下的特殊考量
1. 权限表状态的影响
跳过权限表模式下，MySQL 的权限系统实际上处于"离线"状态。此时：
- 无法使用 GRANT 语句分配权限（因为权限表未加载）
- 只能通过直接修改权限表（如 mysql.user、mysql.db）来设置权限
- 对权限表的修改需要手动刷新才能生效
这意味着在安全模式下创建账号并赋予权限，比正常模式更底层、更复杂。如果仅需要重置密码，操作相对简单；若需要创建完整权限的账号，则需要对权限表结构有较深理解。
2. 与正常创建账号的差异
3. 密码重置与账号创建的区分
安全模式下最常见的需求是重置 root 密码，而非创建新账号。两者的操作流程相似，但目标不同：
- 密码重置：修改已有账号的认证信息
- 账号创建：新增一条用户记录并配置权限
如果目标是恢复管理访问能力，重置 root 密码通常足够；如果确实需要新的业务账号，才执行创建操作。
五、操作后的安全加固
1. 检查并清理遗留风险
从安全模式切回正常模式后，应执行以下检查：
确认无匿名账号
安全模式下可能无意创建或启用了匿名账号（用户名为空）。这些账号会成为安全隐患，应检查并删除。
审查账号主机范围
回顾新创建账号的主机限制，确保没有过度放宽。特别是避免同时存在 'user'@'%' 和 'user'@'localhost' 导致的权限重叠或冲突。
验证密码强度
使用 MySQL 的密码验证插件或外部工具，检查新账号密码是否符合企业安全策略。
2. 更新配置与文档
- 若修改了启动配置文件以进入安全模式，确保已恢复原始配置，避免下次重启时意外进入无认证状态
- 记录账号创建的时间、原因、权限范围，纳入运维审计日志
- 如果是密码重置操作，及时更新密码管理工具或保险柜中的记录
3. 网络层防护
安全模式操作期间，若临时调整了防火墙或绑定地址，操作完成后应恢复：
- 重新限制数据库端口仅对必要 IP 开放
- 若数据库不应直接暴露公网，确认防火墙规则已恢复
六、替代方案与最佳实践
1. 避免频繁使用安全模式
安全模式是"最后手段"，日常运维应建立机制减少对其依赖：
保留备用管理员账号
创建多个具备 SUPER 权限的账号，分散管理风险。避免所有权限集中在单一 root 账号上。
使用密码管理工具
将数据库管理员密码纳入企业级密码管理工具，减少遗忘概率。
定期备份权限表mysql 系统数据库应纳入常规备份策略。权限表损坏时，可通过恢复备份快速修复，无需进入安全模式手动重建。
2. 使用初始化脚本
在自动化部署环境中，通过初始化脚本在数据库首次启动时创建账号，而非事后手动操作。这避免了紧急情况下进入安全模式的需求。
3. 权限最小化原则
无论通过何种方式创建账号，都应遵循最小权限原则：
- 仅授予完成工作所必需的权限
- 区分管理账号、应用账号、只读账号等不同角色
- 定期使用 SHOW GRANTS 审查账号权限，及时回收不再需要的授权
七、总结
MySQL 安全模式下的账号创建是一项应急操作，其核心价值在于绕过损坏或遗忘的权限系统恢复数据库的可管理性。操作流程可概括为：停止服务 → 安全模式启动 → 创建/修复账号 → 刷新权限 → 恢复正常模式 → 验证加固。
由于安全模式完全绕过了认证机制，操作期间数据库处于高度暴露状态，必须严格控制操作时间窗口和网络访问范围。完成操作后，权限刷新和配置恢复是两个不可省略的关键步骤，任何遗漏都可能导致数据库在无防护状态下运行。
对于日常运维，建立完善的账号管理流程、保留备用管理员、定期备份权限表，才是避免依赖安全模式的根本之道。安全模式应作为应急预案而非常规工具，每一次使用都应触发事后复盘，分析为何走到需要绕过权限系统的地步，并优化流程防止再次发生。