MySQL重启时连接中断的根本原因是暴力终止连接导致协议层硬断开；真正避免中断需架构级高可用或实例不杀连接的可控启停，配合客户端连接池主动验证与清理。
MySQL 重启时连接中断的根本原因
在生产环境里，无论是执行 systemctl restart mysqld 还是直接 kill -9 进程，本质上都属于暴力终止所有活跃连接。结果就是，客户端会立刻收到那个熟悉的错误：Lost connection to MySQL server during query。这其实不是配置问题，而是协议层的硬断开——MySQL 根本没有机会通知客户端“我要下线了”。
那么，真正能避免连接中断的路径有哪几条呢？归根结底只有两种：要么让新连接自动切换到备用实例（这依赖于高可用架构），要么让当前实例在不杀死现有连接的前提下，完成配置重载、资源释放甚至主从角色切换。
用 mysqladmin shutdown + mysqld_safe 实现可控停启
相比于直接使用 systemctl，手动控制启动流程可以在关键节点插入检查点，从而减少不可控的时间窗口。当然，这必须配合 --skip-networking 和连接排空（draining）逻辑来使用。
- 首先执行
mysqladmin -u root -p shutdown。这个命令会等待当前事务提交完成，再关闭监听端口，而已建立的连接仍然可以继续执行完手头的语句。 - 启动前，务必确认
/var/lib/mysql的目录权限没有被 systemd 重置（这在 SELinux 启用环境中尤为常见）。 - 使用
mysqld_safe --defaults-file=/etc/my.cnf &来启动。它比直接调用mysqld多了一层异常捕获和自动拉起的能力。 - 启动后，立刻执行
SELECT VERSION(), @@uptime;来验证实例是否真的运行起来了，而不是卡在某个初始化阶段。
配置热加载：哪些参数能 SET GLOBAL，哪些必须重启
不是所有配置都能在线修改。改错了，轻则行为不一致，重则埋下隐患。比如，innodb_buffer_pool_size 在 5.7+ 版本支持动态调整，但仅限于增大；而 max_connections 虽然可增可减，但减小后，新连接会被拒绝，已有连接则不受影响。
- 安全可热改：
slow_query_log、long_query_time、wait_timeout。 - 需谨慎热改：
innodb_buffer_pool_size（只允许增大，且每次最多增 1GB）、sort_buffer_size（只影响新连接）。 - 必须重启：
datadir、socket、port、default_authentication_plugin。 - 验证方式：修改后立刻查询
SELECT @@global.sort_buffer_size;，不要只相信配置文件里的数字。
连接平滑过渡的关键：客户端侧要配合
服务端做得再稳，如果客户端不配合重连，一切也是白搭。很多应用使用长连接池（比如 HikariCP、Druid），它们默认不会主动感知 MySQL 进程重启，只会不断地重试失败连接，直到超时。
- 设置连接池的
connection-test-query=SELECT 1和validation-timeout=3000，确保空闲连接能被及时踢出。 - 启用
failOverReadOnly=false（针对 MySQL Connector/J），避免在主从切换时误判为只读模式。 - 如果使用了 ProxySQL 或 MaxScale 这类中间件，记得在重启前执行：
PROXYSQL ADMIN> UPDATE mysql_servers SET status='OFFLINE_SOFT' WHERE hostgroup_id=1;，等待连接自然耗尽。 - 最简单的兜底方案：在应用部署脚本里加一个
sleep 5，给连接池留出足够的清理时间，不要一重启完就立刻导入流量。
说到底，真正的平滑重启，关键不在 MySQL 自身，而在于整个链路对“连接生命周期”达成了共识。漏掉客户端这一环，服务端做得再优雅也无济于事。
