mysql的restart命令是进程优雅重载，pid不变、连接不断、复制不中断；需由mysqld_safe或systemd守护，配合set persist与set global实现配置零停机生效，但无法解决磁盘满、oom等底层故障。
RESTART不是重启，是进程优雅重载
执行 RESTART 后，MySQL 实例的 PID 不变，端口持续监听，已建立连接不会断开——它不是传统意义上的服务重启，而是由 mysqld_safe 或 systemd 捕获退出码 16 后立即拉起新进程。这对主从维护最关键：主库卡死但未宕机时（比如大事务阻塞 DDL、锁等待风暴），SHUTDOWN 可能卡住几十秒甚至超时，而 RESTART 几乎秒级完成，且不中断复制线程的 socket 连接。
- 必须由守护进程管理：不能前台直接运行
mysqld，否则RESTART直接报错ERROR 1047 (08S01): Unknown command - 客户端会收到一次
ERROR 2006 (HY000): MySQL server has gone away，但自动重连后一切照常，临时表、用户变量等会话状态仍保留 -
server_id和GTID_EXECUTED完全不变，复制链路不会断裂，从库SHOW SLAVE STATUS中的Seconds_Behind_Master可能短暂跳变但立刻恢复
配合PERSIST实现配置“零停机生效”
主从环境中常需动态调参，比如突发流量下临时扩大 max_connections 或收紧 wait_timeout。但 SET GLOBAL 无法修改只读变量（如 innodb_buffer_pool_size），而 SET PERSIST 只写入 mysqld-auto.cnf，下次启动才加载。真正要“立刻生效 + 持久化”，必须组合使用：
- 先执行
SET PERSIST max_connections = 2000，确保配置落盘 - 再执行
SET GLOBAL max_connections = 2000，让当前实例立即应用（对可动态变量） - 最后
RESTART：既刷新所有线程上下文，又强制重载mysqld-auto.cnf，避免后续重启参数回滚
注意：如果只做 SET GLOBAL 而跳过 RESTART，PERSIST 写入的值在下次真实重启前始终不会生效；若只做 RESTART 不提前 SET PERSIST，则配置变更无法持久化。
主从切换中慎用RESTART的边界场景
RESTART 救不了底层资源故障，它只解决 MySQL 用户态进程逻辑卡死问题。以下情况它会失败或无效：
- 磁盘满（
binlog写失败）、内存耗尽（OOM killer 杀进程）、系统级端口冲突：此时mysqld可能根本无法正常退出，守护进程收不到返回码 16，RESTART报ERROR 1227 (42000): Access denied或直接 hang 住 - 主库已彻底宕机（电源断、硬件故障）：
RESTART无法执行，必须走标准 failover 流程 - 启用了
admin_port的场景：RESTART后该端口仍可用，可用于紧急诊断，但需确认从库是否也配置了该端口并监听
真正容易被忽略的是权限和部署形态：执行账号必须有 SHUTDOWN 权限，且 MySQL 必须由 systemd 或 mysqld_safe 管理——Docker 容器里默认用 exec 启动 mysqld，没套守护进程，RESTART 会静默失败。
