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] 下设
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 的失控。
