MySQL连接内存安全指防止连接管理不当引发的OOM或崩溃；需合理设置max_connections与wait_timeout/interactive_timeout（建议300秒），并配合连接池与应用层显式关闭，避免资源堆积。
MySQL 本身不提供“内存安全”这类现代语言层面的保障（比如 Rust 那种编译时内存检查），所谓“连接时的内存安全”，实际是指防止因连接管理不当引发的内存泄漏、OOM 崩溃、或被恶意构造的连接请求触发服务端缓冲区越界——这些在 MySQL 5.7+ 和 8.0 中已有大量加固，但配置和使用方式仍直接影响稳定性。
max_connections 设置过高导致 OOM
MySQL 每个连接会分配独立线程（或协程）及配套内存（如 sort_buffer_size、read_buffer_size），若 max_connections 设为 2000 但未调低单连接内存参数，物理内存可能被迅速耗尽。
- 先查当前值：
SHOW VARIABLES LIKE 'max_connections';，再看已用连接：SHOW STATUS LIKE 'Threads_connected'; - 估算内存上限：单连接基础开销约 256KB～2MB（取决于查询复杂度），建议按公式粗算：
max_connections × (sort_buffer_size + read_buffer_size + join_buffer_size) + innodb_buffer_pool_size≤ 物理内存 × 0.7 - 生产环境慎用
SET GLOBAL max_connections = 2000这类硬调；更稳妥的是在my.cnf中设合理值，并配合应用层连接池（如 PDO 的 persistent connection 或第三方 pool）复用连接
wait_timeout 和 interactive_timeout 过长造成连接堆积
客户端断开后，MySQL 不会立刻释放连接资源，而是等超时才回收。若这两个值设为 86400（24 小时），而应用又没正确 close 连接，Threads_connected 会缓慢爬升直至 hit max_connections。
- 默认值通常为 28800（8 小时），对 Web 应用偏高；建议设为
300（5 分钟）或600（10 分钟） - 修改命令：
SET GLOBAL wait_timeout = 300;（仅当前会话生效需加GLOBAL） - 注意：
interactive_timeout影响 mysql CLI 等交互式客户端，一般与wait_timeout同步设置即可 - 应用代码里仍要显式调用
mysqli_close()或让 PDO 对象离开作用域——超时只是兜底，不是替代方案
认证阶段缓冲区滥用（尤其 MySQL 8.0+ caching_sha2_password）
MySQL 8.0 默认认证插件 caching_sha2_password 在握手阶段需更多内存处理 SHA2 加密，若客户端反复重试错误密码，可能触发临时内存峰值；旧客户端（如 PHP 7.3 及以下 mysqli）若未启用 mysqlnd 扩展，还可能因协议解析缺陷导致栈溢出。
- 确认插件兼容性：
SELECT host, plugin FROM mysql.user WHERE user = 'your_user'; - 如需兼容老客户端，临时降级：
ALTER USER 'user'@'host' IDENTIFIED WITH mysql_native_password BY 'pwd'; FLUSH PRIVILEGES; - 禁止弱密码爆破：在
my.cnf中启用validate_password插件，并设validate_password.length = 12等策略 - 防火墙层限制单 IP 连接频次（如 iptables 或云厂商安全组），比 MySQL 层拦截更早掐断恶意流量
真正关键的不是“MySQL 是否内存安全”，而是你是否把连接生命周期控制在可预期范围内——从配置参数、客户端行为到网络中间件，每一环松动都可能让内存压力传导至 mysqld 进程崩溃。尤其注意 max_connections 和 wait_timeout 的组合效应，它们比任何单点调优都更容易引发连锁故障。
