MySQL 9.4 的 server_memory 怎么用：限制默认内存估算，不是给 InnoDB 加缓存

升级到 MySQL 9.4 后，如果你在配置文件里看到 server_memory，先别把它当成“mysqld 最多只能用这么多内存”。它真正控制的是服务启动时，MySQL 用多少物理内存来推导部分内存相关变量的默认值；值设得大于机器或容器可用内存时，服务器反而可能直接拒绝启动。

先把 server_memory 的作用域和默认值看准

MySQL 9.4 的变量说明把它定义为整数型、Global、Dynamic=No，默认值为 0。这个 0 更适合读成“不要额外指定一个用于默认值计算的内存上限”，而不是“服务器不使用内存”。配置入口是启动参数 --server-memory=，常见写法如下：

[mysqld]
server_memory=16G

启动后可以先看实例实际采用的值：

SHOW GLOBAL VARIABLES LIKE 'server_memory';

如果部署在容器里，还要把 container_aware 一起看。官方规则是：关闭时按总物理内存校验，开启时把容器资源限制纳入校验。这里的关键是“校验和默认计算”，不是给每个连接发放一块 16G 的可用额度。

查看 MySQL 9.4 受影响的默认变量

官方列出的影响面很窄，先按这张表核对，不要把所有带 buffer 或 cache 的变量都算进去。

要区分“编译默认值、配置文件值、运行中值”，可以保留两组输出：

mysqld --no-defaults --verbose --help
mysqld --verbose --help
SHOW GLOBAL VARIABLES LIKE 'temptable_max_ram';
SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_size';

第一条忽略选项文件，第二条会读取选项文件，SQL 则显示当前运行实例。三者不一致并不自动说明配置错误，可能只是配置文件或启动参数覆盖了默认值。

用三条证据区分默认值与运行时上限

第一条证据是 Dynamic=No：不能用 SET GLOBAL server_memory=... 临时改变它，调整后需要按启动配置重新加载。第二条证据是影响项清单：文档只点名 temptable_max_ram 和有条件的 innodb_buffer_pool_size，所以不能据此推导“所有会话内存都会被封顶”。第三条证据是启动行为：当设置值高于可用物理内存或容器内存限制时，MySQL 会报告错误并不启动。

因此，线上看到内存持续上涨时，排查方向仍应落到连接数、单连接缓冲区、临时表、InnoDB 工作集和容器限制等具体对象，不能只改 server_memory。它解决的是默认配置估算的边界问题。

上线前按物理机与容器边界反向验证

物理机部署先记录可用物理内存，再决定是否显式设置 server_memory；容器部署则同时核对 container_aware 和 cgroup 限制。设置值后，保留启动参数、配置文件来源、两条 mysqld --verbose --help 输出及错误日志中的资源信息。升级回滚时，删除新增参数并恢复原来的 InnoDB 专用配置，比盲目把值改成更大更安全。

常见问题

server_memory 能限制 MySQL 进程的总 RSS 吗？

不能。它用于默认值计算和启动边界校验，不是进程级运行时硬上限。

设置了 server_memory 后一定会改变 innodb_buffer_pool_size 吗？

不一定。还要满足启用 innodb-dedicated-server 且设定值大于 1GB，才进入官方列出的影响条件。

容器里只设置 server_memory 就够了吗？

不够。还要确认 container_aware 与容器实际内存限制，否则默认计算和启动校验可能与预期不同。