MySQL无单用户内存限制，权限本身不分配内存；innodb_buffer_pool_size是全局共享缓存，不影响单连接内存占用；真正导致OOM的是sort_buffer_size等per-connection参数及连接数，8.0.28+可用connection_memory_limit硬限单连内存，OS层cgroup v2才是终极兜底。

MySQL 没有“单用户内存限制”这个概念，所谓“权限过大导致 OOM”，本质是误判——权限（GRANT）本身不分配内存，真正吃光内存的是连接行为和查询模式。关键得控住 per-connection 内存 + 连接数，而不是砍权限。

为什么 innodb_buffer_pool_size 不能解决单用户 OOM

这个参数是全局共享的，所有连接共用一块缓存池，改它只影响缓存命中率和磁盘 I/O，不会让某个用户多占或少占内存。哪怕你把 innodb_buffer_pool_size 调到 1G，一个恶意用户开 200 个连接、每个执行大 ORDER BY，照样能靠 sort_buffer_size × 200 把内存打爆。

• innodb_buffer_pool_size 修改后需重启或在线 resize（5.7.5+），但对单连接内存无约束力
• 它的单位是字节，配置文件里写 4G 比 4294967296 更安全，避免溢出解析错误
• 若 SHOW STATUS LIKE 'Innodb_buffer_pool_reads'; 持续 > 10/s，说明缓存太小，但这和 OOM 无关，只是慢

真正该调的 per-connection 参数有哪些

这些才是随连接数线性放大的内存来源，一个连接就分一份，100 个连接就是 100 倍：

• sort_buffer_size：默认 256KB，大排序时分配；生产建议 ≤ 2M，绝不要设成 8M —— 小并发就可能触发 OOM
• read_buffer_size：默认 128KB，全表扫描启用；保持默认或调低，不建议放大
• join_buffer_size：哈希连接用，同样 per-connection；默认 256KB，高并发下建议 ≤ 1M
• tmp_table_size 和 max_heap_table_size 必须严格相等，否则内存临时表静默退化为磁盘表，既慢又耗 I/O

示例：在 my.cnf 的 [mysqld] 下设

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

sort_buffer_size = 1M
read_buffer_size = 128K
join_buffer_size = 512K
tmp_table_size = 64M
max_heap_table_size = 64M

MySQL 8.0.28+ 可用的真·单连接内存限制

这是唯一原生支持“按连接限内存”的机制，但仅限 8.0.28 及以上版本：

• connection_memory_limit：单位字节，设为 2097152 即 2MB，超限直接断连并报错 ERROR 4082 (HY000): Connection closed. Connection memory limit 2097152 bytes exceeded.
• 必须配合 SET GLOBAL global_connection_memory_tracking = ON; 才能统计，但开启有轻微性能损耗
• 该限制只管当前连接生命周期内的内存申请（如大结果集、临时表、排序缓冲），不管 innodb_buffer_pool 这类全局资源
• 不能通过 CREATE USER 绑定，是全局开关，所有连接统一受控

最可靠的兜底方案：cgroup v2 硬隔离

无论 MySQL 版本新旧，只要 Linux 内核 ≥ 4.15 且启用 cgroup v2，这就是唯一能防住 RSS 内存无限上涨的手段：

• 确认启用：mount | grep cgroup 输出含 type cgroup2
• 裸机部署推荐用 systemd：在 /etc/systemd/system/mysqld.service.d/override.conf 加

[Service]
MemoryMax=4G

• 容器环境（Docker/Podman）默认走 cgroup v2，启动时加 --memory=4g 即可
• 注意：memory.high 是软限（触发回收），memory.max 才是硬限，OOM killer 触发前就会 kill 掉超额进程

别指望靠 max_connections 或 MAX_USER_CONNECTIONS 完全防住 OOM——它们只控连接数，不控每个连接实际干了什么。真正的风险点永远在那些没被显式限制的 per-connection 缓冲区，以及 OS 层面对 mysqld 进程整体 RSS 的失控。