必须同时设置wait_timeout和interactive_timeout并写入配置文件重启生效，因为新连接的wait_timeout初始化值继承自interactive_timeout，只改一个会导致配置失效。
MySQL连接超时不是网络问题，而是服务端主动断开空闲连接——核心要调 wait_timeout 和 interactive_timeout，且必须同步设、写配置、重启生效，光执行 SET GLOBAL 没用。
为什么改了 wait_timeout 还是断连？
因为新连接的会话级 wait_timeout 值，初始化时直接继承自全局 interactive_timeout。哪怕你只改了 wait_timeout 的全局值，只要 interactive_timeout 没动，新连接仍按旧值初始化，等于白调。
- 绝大多数应用（Java、Python、Node.js）建的是非交互式连接，走
wait_timeout，但初始化依赖interactive_timeout - 命令行、Workbench 等交互式工具才真正走
interactive_timeout -
SET GLOBAL wait_timeout = 300只影响后续新建连接的初始值，不改变已存在连接，也不影响interactive_timeout的取值逻辑 -
配置文件里只写
wait_timeout = 300而漏掉interactive_timeout，MySQL 会回退到编译默认值（通常是 28800）
怎么永久修改才真正生效？
必须编辑 MySQL 配置文件，在 [mysqld] 段落下**同时声明两个参数**，然后重启 mysqld 进程。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 配置路径常见为
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf - 确认写在正确的
[mysqld]段里——多个段时，只有最后一个生效；!includedir下的文件按字母序覆盖 - 正确写法：
[mysqld] wait_timeout = 300 interactive_timeout = 300
- 改完必须执行
systemctl restart mysql（或service mysqld restart），reload不生效 - 验证是否生效：
SHOW VARIABLES LIKE 'wait_timeout';和SHOW VARIABLES LIKE 'interactive_timeout';，两个值必须一致且为你设的数值
云数据库（如阿里云 RDS）怎么调？
不能直接改配置文件，必须通过控制台「参数模板」调整，且受平台限制。
- 登录控制台 → 找到对应 RDS 实例 → 进入「参数设置」→ 编辑参数模板
- 搜索
wait_timeout和interactive_timeout，填相同值（比如 300） - 注意取值范围：阿里云 RDS 最小支持 10 秒，最大 31536000 秒；腾讯云 CDB 类似，超出范围会保存失败
- 修改后需「应用参数模板」→ 实例自动重启（部分版本支持平滑切换，但仍有秒级闪断）
- 别信“已提交”，一定要查
SHOW VARIABLES确认实际运行值
应用层不配合，数据库调再小也没用
就算把 wait_timeout 设成 300 秒，如果连接池自己设了更长的存活时间，连接照样会在池子里“僵死”直到被 MySQL 断开，下一次取用就报 Lost connection to MySQL server during query。
- HikariCP：设
maxLifetime≤ 250000（比 300 秒短），并开启connection-test-query=SELECT 1或connection-init-sql - Druid：设
minEvictableIdleTimeMillis≤ 250000，且testWhileIdle=true - PyMySQL / mysql-connector-python：确保每次执行前调用
ping(True)，或设autocommit=True避免事务卡住连接 - 千万别设
autoReconnect=true—— 它在 MySQL 5.7+ 已被弃用，且掩盖真实问题
最容易被忽略的是：应用连接池的空闲检测间隔和数据库超时值之间必须留出缓冲（建议至少 30 秒差），否则刚检测完连接还活着，几秒后就被 MySQL 关了。
