max_connections不是并发能力开关，需先查max_connections、threads_connected和max_used_connections交叉验证真实压力；临时调用set global需权限且重启失效，永久修改须在[mysqld]段写入配置文件并重启，同时同步调高ulimit-n、降低wait_timeout，并优先优化应用层连接池。
max_connections 不是“设了就完事”的参数，它直接决定你能不能扛住并发请求，也直接暴露服务器资源瓶颈。调高它前，先确认你真需要——很多“Too many connections”错误其实是连接泄漏或没用连接池导致的，不是参数不够。
怎么查当前 max_connections 和实际使用情况
登录 MySQL 后，别只看一个值，要交叉验证：
-
SHOW VARIABLES LIKE 'max_connections';—— 看理论上限 -
SHOW STATUS LIKE 'Threads_connected';—— 看此刻活连接数 -
SHOW STATUS LIKE 'Max_used_connections';—— 看历史峰值，比当前值更有参考价值
如果 Max_used_connections 长期接近 max_connections，再考虑调；如果只是偶发尖峰，优先查应用是否漏关连接或没配连接池。
临时改：用 SET GLOBAL 快速验证
适合测试、压测或紧急扩容，但重启即失效：
- 执行
SET GLOBAL max_connections = 500;（注意必须有SYSTEM_VARIABLES_ADMIN权限） - 立刻执行
SHOW VARIABLES LIKE 'max_connections';确认生效 - 别跳过验证步骤——有些版本（尤其云数据库）会拒绝该命令，返回
ERROR 1238 (HY000): Variable 'max_connections' is a read only variable
这个操作不触发配置重载，也不影响已建立的连接，但新连接会按新值限制。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
永久改：改配置文件 + 重启，但路径和写法容易错
Linux 下最常见错误是改了错的文件，或没加 [mysqld] 段落头：
- 确认配置文件位置：
/etc/my.cnf、/etc/mysql/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf（Ubuntu/Debian 常用后者） - 编辑时必须放在
[mysqld]块内，不能写在[client]或文件开头；否则 MySQL 启动时忽略 - 写成：
[mysqld] max_connections = 500
- 改完执行
sudo systemctl restart mysql（或mysqld，取决于你的服务名），别只 reload
Windows 用户注意：my.ini 文件通常在 MySQL 安装目录或 C:\ProgramData\MySQL\MySQL Server X.X\ 下，同样必须套在 [mysqld] 里。
调高后真正卡住你的往往不是 MySQL 本身
max_connections 只是第一道门，后面还有三道墙：
-
操作系统级限制：每个连接对应一个线程，受
ulimit -n（文件描述符数）和/proc/sys/kernel/pid_max限制；ulimit -n小于max_connections时，MySQL 启动失败或中途报错 -
内存爆炸风险：每个连接默认分配
sort_buffer_size、read_buffer_size等内存；500 连接 × 2MB ≈ 1GB 额外内存开销，物理内存不足会触发 OOM Killer -
云厂商硬限制：阿里云 RDS、AWS Aurora 等对
max_connections有实例规格强约束，即使你配了 2000，也可能被后台截断为 1000
真正稳定的方案不是无脑调高 max_connections，而是让应用用 HikariCP 或 Druid 连接池控住实际连接数，再把 wait_timeout 从默认 28800 秒（8 小时）降到 300 秒以内，主动回收空闲连接。
