MySQL 8.0 的 RESTART 命令本质是优雅重载进程：由 mysqld_safe 或 systemd 捕获返回码16后立即拉起新实例，不中断端口监听、不释放 socket、不丢弃已连会话状态，仅清空查询缓存、重载配置、重初始化线程池。
MySQL 8.0 的 RESTART 命令不是“重启服务”，而是“优雅重载进程”
很多人误以为 RESTART 是等价于 systemctl restart mysql，其实完全不是。它本质是向 mysqld_safe（或 systemd）发送一个特殊退出信号（返回码 16），由守护进程捕获后立即拉起新实例——整个过程不中断监听端口、不释放 socket、不丢弃已建立连接的会话状态（如临时表、用户变量等），只是清空查询缓存、重载配置、重初始化线程池。这对高可用切换中“秒级恢复写入能力”极为关键。
主从切换时，RESTART 能绕过传统 SHUTDOWN + 启动的窗口期
在半同步复制 + GTID 场景下，一次主库故障后的标准 failover 流程是：停主库 → 提升从库为新主 → 切换应用连接。但若主库未彻底宕机，只是卡死或 hang 住（比如锁等待风暴、大事务阻塞 DDL），此时 SHUTDOWN 可能长时间无响应，而 RESTART 会强制触发守护进程重启逻辑，实际耗时通常 SHUTDOWN 超时（默认 60 秒）再人工 kill -9 再手动启动快得多。
-
RESTART要求账号有SHUTDOWN权限，且 mysqld 必须由mysqld_safe或 systemd 管理（不能直接前台运行） - 执行后客户端会收到
ERROR 2006 (HY000): MySQL server has gone away，但自动重连后即可继续使用 - 不会改变
server_id或 GTID_EXECUTED 集合，不影响复制链路连续性
RESTART 与 PERSIST 配合，让配置变更真正“零停机生效”
高可用架构中常需动态调参，比如突发流量下临时调高 max_connections 或降低 wait_timeout。MySQL 8.0 支持 SET PERSIST max_connections = 2000，但该值仅在下次启动时加载；若想立刻生效又不中断服务，必须先 SET GLOBAL，再 RESTART ——这样既能刷新所有线程上下文，又能把 PERSIST 写入的 mysqld-auto.cnf 立即载入，避免重启后参数回滚。
- 单独用
SET GLOBAL无法修改只读变量（如innodb_buffer_pool_size），必须靠RESTART -
RESTART不会丢失未提交事务（因为 InnoDB redo log 和双写机制保障了崩溃恢复） - 注意：如果启用了
admin_port，RESTART后该端口仍可用，可用于紧急诊断
容易被忽略的限制：它救不了磁盘满、OOM 或 binlog 写失败这类底层故障
RESTART 依赖守护进程能正常接管退出，一旦出现以下情况，它会直接失败并报错：ERROR 1047 (08S01): Unknown command（说明未启用该功能）、ERROR 1227 (42000): Access denied（权限不足）、或更隐蔽的 mysqld_safe 检测到磁盘空间不足 / 内存分配失败而拒绝重启。这时候必须先人工介入清理资源，否则 RESTART 只是反复触发失败循环。
真正决定高可用切换效率的，从来不是单点命令多快，而是整个链路是否可预测、可收敛。RESTART 的价值在于把“不可控的宕机恢复”压缩成“可控的进程重载”，但前提是你的部署模式、监控覆盖和守护进程健壮性都已就位——否则它只是个更快的报错按钮。
